ietf-smtp
[Top] [All Lists]

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

2001-07-27 11:45:57

On Fri, Jul 27, 2001 at 10:51:07AM -0400, Keith Moore wrote:

Servers can tolerate such clients if they wish.  But clients that send 
anything other than a TLS 1.0 Hello message shouldn't expect to 
interoperate with servers that assert STARTTLS.  The way the TLS
protocol is designed, the burden is on the client to send an appropriately
formatted Hello message.

The TLS protocol includes provisions for protocol version negotiation.

Yes, I understand.  It's the SSL 2.0 Hello messages that I'm concerned 
about, not SSL 3.0 Hello messages with a maximum version # >= 3.1.

Even such SSL 3.0 backwards compatible Client Hello messages are not
strictly TLS 1.0, so servers might reject them out of spite.


And yes, this is really a bug in the TLS spec, and maybe that's where
it should be fixed.  

But given that SMTP STARTTLS has *never* supported anything less than
TLS 1.0

RFC 2487 (January 1999) says

   TLS [TLS], more commonly known as SSL, is a popular mechanism for
   enhancing TCP communications with privacy and authentication. TLS is
   in wide use with the HTTP protocol, and is also being used for adding
   security to many other common protocols that run over TCP.

The version number (TLS 1.0) appears only in the 'References' section.
It is clear that RFC 2487 is intended primarily for TLS 1.0, but the
RFC does not discuss differences between TLS 1.0 and the earlier SSL
protocols, and it does not discuss backwards compatibility issues.  I
assume this was mainly an oversight -- the 'more commonly known as
SSL' part reveals some fuzziness with respect to protocol version
differences, and I doubt that TLS 1.0 was 'in wide use with the HTTP
protocol' in January 1999.  (The TLS 1.0 RFC is from January 1999 too.
Microsoft browsers have supported TLS 1.0 for some time, but it still
is disabled by default.  Netscape may have started to support TLS 1.0
by now.  TLS with HTTP is in wide use among Lynx-SSL users, though.)


        I have a difficult time understanding why SMTP client authors
thought it was acceptable to send SSL 2.0 Hello messages.  Maybe they just 
blindly linked in SSL libraries without telling them what protocol
version to use?

Or they chose a pragmatic approach.  Some alleged 'STARTTLS' servers
only support SSL 3.0.  These are clearly broken, but making clients
backwards compatible with them still looks like a good idea.


I think it's quite reasonable to document the fact that lots of SMTP
clients have been shipped that send out SSL 2.0 Hello messages, and
that servers might want to support these messages (you could even
say RECOMMENDED) in addition to TLS 1.0 messages.  But in the future, 
clients should send TLS 1.0 Hello messages.

In the future, yes.  But I am also concerned about the present.


I have limited faith in a WG's ability to enumerate all existing 
implementations, and I don't like the WG deciding that broken 
implementations are more deserving of compatibility with future
versions of the standard, than ones that followed the original spec.

The successor of RFC 2487 with those backwards-compatibility-compatibility
requirements will actually be easier to implement than RFC 2487. Here's
some RFC 2487 fun:

   After receiving a 220 response to a STARTTLS command, the client
   SHOULD start the TLS negotiation before giving any other SMTP
   commands.

I.e., when the server expects a Client Hello message (in whatever
format), it may receive an SMTP command in plain ASCII instead if the
client has decided that it does not want to use TLS after all.
I bet that not only most clients are 'broken' (because they use
SSL 2.0 compatible Client Hello messages), but all servers are 'broken'
too because they cannot handle cleartext SMTP commands directly after
they have accepted STARTTLS.

This, too, should be changed.  This time the change to the
specification will magically repair lots of broken servers at the risk
of turning some conforming clients into non-conforming ones.


These are two specification changes that will adjust the RFC to
reality.  There's a minor chance that some previously conforming
implementations suddenly will stop to be conforming, but there's
serious doubt that this kind of conforming implementation has ever
existed -- and if they did, they were not too useful because they
could not interoperate with the rest of the known world.


As I said before, essentially all existing
STARTTLS clients are 'broken' in the sense that they use backwards
compatible Client Hello messages; so STARTTLS servers not supporting
backwards compatible Client Hello messages wouldn't be able to survive
in the wild.  

not necessarily true - it just means that people wouldn't use the
STARTTLS feature of the client.

OK, they might have been able to survive, but surely they were hiding
well.  Make that 'publicly referenced STARTTLS servers', then.
While I don't know what people do in the privacy of their intranets,
I am not aware of compatibility problems with public MXes insisting on
pure TLS 1.0 Client Hello messages.


-- 
Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

<Prev in Thread] Current Thread [Next in Thread>