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

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 <[email protected]>
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