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

> >       Note that neither clients nor servers are required to actually
> >       support protocol versions other than TLS 1.0; but the above rules
> >       make sure that clients can operate in a backwards-compatible mode
> >       without risking interoperability with servers following the
> >       current specifications.

> This is completely bogus.  The reason we have a TLS specification
> is so people can get interoperability by implementing it.  If they
> instead implement some earlier specification that isn't TLS, they're
> not meeting the requirements of the standard.  SMTP servers that claim
> to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN,
> full stop.  Similarly, clients that issue a STARTTLS command and don't
> send TLS 1.0 Hello messages are also BROKEN, full stop.

Sigh. It is my understanding that there's a fair amount of SSL out there
masquerading as TLS. And using SSL is certainly better than using nothing.

Nevertheless, I think Keith is right. We have to take the long view. We cannot
cannot afford to be wishy-washy about this, much as short-term pragmatism would
say otherwise.

> If a server wants to accept older Hello messages, that's its own
> business.  And servers would do well to parse older Hello messages
> and continue with the TLS dialog even if they don't accept the
> resulting client authentication as valid and don't treat the
> negotiated session as if it were secure - just because it makes
> for better error recovery.  But client implementations shouldn't
> expect that sending older Hello messages are going to make them
> interoperable with servers that advertise STARTTLS.

Exactly. We're not precluding nonstandard behavior, but we're also not
condoning it.

> > >     An SMTP client can partially protect against these attacks by
> > >     recording the fact that a particular SMTP server offers TLS during
> > >     one session and generating an alarm if it does not appear in the
> > >     EHLO response for a later session. The lack of TLS during a session
> > >     SHOULD NOT result in the bouncing of email, although it could result
> > >     in delayed processing.

> > > it seems quite reasonable to explicitly configure a client to insist
> > > on the server supporting TLS, and refusing to send a message to the
> > > server if it doesn't advertise STARTTLS.  this also seems safer than
> > > the "automatic discovery" mechanism above.

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

At one point I toyed with the idea of a SASL mechanism based on a
Diffie-Hellman exchange. Clients and servers would remember the credentials
established from past exchanges and use them to mitigate man in the middle
attacks.

I gave up on this idea for precisely the reason Keith cites: Our SMTP
infrastucture is just too variable for such a scheme to work in wide
deployment. There will be too many times when retained information will be at
odds with infrastructure shifts and messages will fail to transfer.

				Ned