Re: Serious design flaw in STARTLS documents

[John Gardiner Myers <jgmyers@xxxxxxxxxxxx>]

Paul Hoffman / IMC wrote:
> John: can you provide some wording
> for what I should say about SASL announcements before and after STARTTLS?

Upon completion of the TLS handshake, the SMTP protocol is reset to the
initial state (the state in SMTP after a server issues a 220 service
ready greeting).  The server MUST discard any knowledge obtained from
the client, such as the argument to the EHLO command, which was not
obtained from the TLS negotiation itself.  The client MUST discard any
knowledge obtained from the server, such as the list of SMTP Service
Extensions, which was not obtained from the TLS negotiation itself.  The
client SHOULD send an EHLO command next.

The list of SMTP Service Extensions returned in response to an EHLO
command received after the TLS handshake MAY be different than the list
returned before the TLS handshake.  For example, a server might not want
to advertise support for the SASL EXTERNAL mechanism [SASL] [SMTP-SASL]
unless a client has sent an appropriate client certificate during a TLS
handshake.  A server MUST NOT return the STARTTLS extension in response
to an EHLO command received after a TLS handshake has completed.


[Add to Security Considerations]

Any protocol interactions prior to the TLS handshake are performed in
the clear and may be modified by an active attacker.  For this reason,
section XXX requires that clients and servers discard upon completion of
the TLS handshake any knowledge obtained prior to the start of the TLS
handshake.