ietf-smtp
[Top] [All Lists]

Re: RFC 3207 STARTTLS

2008-10-23 04:34:17

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:
C: STARTTLS
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.  <...>
...
   handshake_failure
      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 ?

  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 
originator
         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.

-- 
/Matti Aarnio   <mea(_at_)nic(_dot_)funet(_dot_)fi>

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