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

On Thu, Jul 26, 2001 at 06:08:38PM -0400, Keith Moore wrote:

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

>> I agree that such servers are broken.  But clients may want to
>> tolerate them anyway, and it is easy for TLS-only servers to tolerate
>> clients tolerating such broken servers.

> 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.
The client's Client Hello message indicates a maximum supported
version number and a minimum supported version number.  The maximum
supported version certainly must be 3.1 (= TLS 1.0) for clients using
STARTTLS (and servers must be able to handle higher version numbers
that may be used in the future when a new revision of the TLS
specification assigns a higher version number).  The minimum supported
version number must be lower than 3.1 if the client wants to achieve
backwards compatibility.

If a client wants backwards compatibility with SSL 3.0 servers, the
only difference is that the record header of the Client Hello message
may contain version number 3.0 rather than 3.1.  The 'client_version'
field in the actual Client Hello message still will be 3.1 (or
higher).  This is easy for servers to handle -- and this is exactly
how protocol version negotiation between different versions of TLS
will work in the future.

Backwards compatibility with SSL 2.0 servers is a little more
difficult in theory, but turns out to be less error-prone in practice.
The Client Hello message has some structural differences, and the SSL
3.0/TLS 1.0 record format is not used; so servers have to copy some
data around to transform the Client Hello message into the TLS 1.0
format.  Version number 2.0 is not explicitly contained in the
message, and this avoids certain bugs in broken SSL/TLS server
software that is probably still around.

The problem with the TLS RFC is that it describes how backwards
compatibility can be achieved, but not in a way such that
interoperability is guaranteed:


E. Backward Compatibility With SSL

   [...]

   TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
   Version 2.0 client hello messages [SSL2]. TLS servers should accept
   either client hello format if they wish to support SSL 2.0 clients on
   the same connection port. [...]


This means that TLS 1.0 clients that support SSL 2.0 servers cannot
necessarily communicate with TLS 1.0 servers that do not with to
support SSL 2.0 clients -- even though both the client and the server
are willing to use TLS 1.0.



>>>             Similarly, clients that issue a STARTTLS command and don't 
>>> send TLS 1.0 Hello messages are also BROKEN, full stop.  

>> Can you name an existing SMTP client with STARTTLS support that is not
>> 'broken' by your definition?  

> does it matter?  the current specification defines rules such that if you 
> follow them, you should be able to interoperate.  what you're proposing 
> to do is to change the rules so that servers that followed the old 
> spec, might not interoperate with clients that follow the new spec.

This is true, but I seriously doubt that there are any servers that
would have such problems.  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.  The change from RFC 2487 is just meant to adjust the
STARTTLS specification to reality.  After all this is not about some
ITU networking protocol that should merely look nice on paper :-)



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