Re: Serious design flaw in STARTLS documents

John and all,

John Myers wrote:

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

  I agree with you assessment here John.  I have argued with Chris on this
matter
several times some time ago now.  Hence we went ahead and developed
our own Interface Facility or MLPI to thwart some of these types of concerns.

Regards,


--
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email protected]