Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard

Keith Moore <[email protected]> writes:
> > This was discussed at length during the first round on this document, 
> > and the consensus was to use the words that are here. 
> 
> This is also bogus.  People need to be able to change server configurations,
> or switch from one server to another, without it causing bounced mail.
> Experimenting with TLS on an SMTP server (and turning it off later)
> should not cause subsequent mail for that SMTP server to bounce.
I'm afraid that Keith is right here. Unfortunately, this leaves
STARTTLS very vulnerably to active attack. 


Idle speculation: Perhaps a compromise position would be to allow this
sort of caching but to limit the period for which it may be
used. E.g. the cache must expire in no more than 1 day. This would
produce some bouncing but limit the scope of that bouncing. The
advantage would be that the attacker would have to mount a concerted
active attack over a period of a day.

> > >and if there is explicit configuration to require STARTTLS along a
> > >particular path, it seems perfectly reasonable for the client to refuse to
> > >relay the message for as long as the server fails to support STARTTLS,
> > >which could eventually result in a bounced message if delivery times out.
> > 
> > Again, that was not the consensus of the group.
> 
> the proposal needs consensus of the IETF, not just "the group".
> "the group" probably needs to go back and think about this again.
> (what group is this anyway?)
> 
> I find it completely bizarre that "the group" thinks that it's okay to
> fall back to an insecure path if the client knows that a secure path
> is supposed to be available. 
I agree with Keith here as well. However, note that said configuration
would have to include the expected identify of the server as well as
the fact that you expected TLS. Otherwise, a different form of active
attack is possible.

-Ekr