Re: Serious design flaw in STARTLS documents

Correct.  I can't remember whether I put such language into the
draft-ietf-tn3270e-tls-telnet-00.txt.....but I certainly will ensure
that negation of previously-negotiated Telnet options appears in the
next draft. Some thought needs to be given to previous negotiations that
*are* secure, and whether or not to allow these to continue to be in
force.

/msb


John Myers wrote:
> 
> In implementing draft-hoffman-smtp-ssl-05.txt and
> draft-newman-tls-imappop-03.txt, I have found a security problem and
> interoperability problem which I believe should be addressed before
> these documents are published as RFC's.
> 
> The protocols as specified are likely to lead to client implementations
> vulnerable to a man-in-the-middle attack directed at
> capabilities/service-extensions OTHER than the STARTTLS extension
> itself.  This occurs if a client believes extensions it received before
> starting up TLS.
> 
> The fix is to require that the client discard all knowledge of
> capabilities/extensions it received prior to negotiating TLS.  After
> negotiating TLS, the client must re-query for capabilities/extensions.
> The documents could save a round trip by stating that following a TLS
> negotiation, the server must immediately send a list of
> capabilities/extensions to the client.
> 
> This fix would also address the interoperability problem, which is that
> the list of available SASL mechanisms is likely to depend on the state
> of the TLS negotiation.  A server does not want to advertise the SASL
> EXTERNAL mechanism unless it accepts the client's TLS certificate.  A
> server does not want to advertise the SASL PLAIN mechanism unless there
> is sufficient encryption to protect from passive sniffing any password
> the client would send in response.
> 
> Since STARTTLS is an extension which is only enabled by active
> negotiation of both parties, it is reasonable for it to amend any
> restrictions in the SMTP or IMAP protocols against the list of
> capabilities/extensions changing due to session state.