[Top] [All Lists]


2008-10-23 06:02:40

Matti Aarnio wrote:

On Thu, Oct 23, 2008 at 12:44:05AM -0700, Philip Guenther wrote:
On Thu, 23 Oct 2008, Ivar Lumi wrote:
After reading RFC 3207, i found probably non documented item.

For example:
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>

Now if negotiation fails, whats then ?
Send error ? close connection ?
Whats the proper action ?
RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol. So follow the rules over in the TLS specification. To quote RFC 2246:

7.2.2. Error alerts

  Error handling in the TLS Handshake protocol is very simple. When an
  error is detected, the detecting party sends a message to the other
  party. Upon transmission or receipt of an fatal alert message, both
  parties immediately close the connection.  <...>
     Reception of a handshake_failure alert message indicates that the
     sender was unable to negotiate an acceptable set of security
     parameters given the options available.  This is a fatal error.

(Other errors may apply, depending on exactly what you mean by "negotiation fails".)

I.e., if your end detects a fatal error, send a fatal error alert and close the connection. If your end receives a fatal error alert, close the connection.
So far so good, but what to do at SMTP level ?
If the error happened once TLS negotiation started, then the server has no choice but to close the connection at SMTP level.

 a)  If running as "opportunistic encrypter", one can degrade the connection
     to plain and try to send the message (by making a new connection and not
     trying to enable TLS).

   a2)  Possibly sending additional informational warning to the email 
        about the failure to run opportunistic encryption, when the message was
        sent over non-encrypted connection after STARTTLS fault.

 b)  If the address specific routing sets a policy is to send given destination
     only via encrypted and with certificate validated TLS connetion, and it
     fails, then the only way is to return the message back to originator.

Most cases of using TLS and server certificates on SMTP are not getting even
certificate CN quite right.  Certificate verification is purely black magic.
Yes, this could have been better documented.

<Prev in Thread] Current Thread [Next in Thread>