Re: Serious design flaw in STARTLS documents

Chris Newman wrote:
> 
> On Tue, 21 Apr 1998, John Gardiner Myers wrote:
> > ...
> >
> > 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.
> 
> I'm a bit concerned about this wording.
> 
> If the user has already authenticated using a SASL mechanism with the SMTP
> AUTH extension, is that state discarded?
> 
> I'm also concerned about the implications for starting TLS later on in an
> IMAP, ACAP or POP session.  I see two viable options:
> 
> (1) STARTTLS is only permitted prior to authentication and always causes
> new capability negotiations.
> 
> (2) STARTTLS is permitted at any time and has no effect on authentication
> state.  Clients SHOULD re-issue the command for capabilities.
> 
> I think (2) is the correct answer.  In a situation where active attacks
> aren't a problem, but privacy is, then it's just a waste to reset protocol
> state or discard capability information.

I think (1) is the correct answer.  You want to avoid having to do TLS
on top of a SASL security layer, just as you want to avoid having to do
TLS on top of TLS.  If you authenticate with SASL but do not negotiate a
security layer, an active attacker can use your privileges between the
SASL authentication and the TLS handshake.

If you think you have a situation where active attacks aren't a problem,
but privacy is, I think you've mis-identified your threat model.