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

Keith Moore <[email protected]>:

>>> Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?

>>       Clients MAY use backwards compatible SSL Client Hello message
>>       formats.  However, except for SSL session resumption, Client
>>       Hello messages MUST be suitable for negotiating TLS 1.0 or later
>>       (i.e. the version field of SSL 2.0 compatible Client Hello
>>       messages or the client_version field of SSL 3.0 compatible Client
>>       Hello messages must be at least 3.1).
>> 
>>       Servers MUST be able to understand backwards compatible SSL
>>       Client Hello messages, provided that the client indicates that
>>       it supports TLS 1.0 or later.
>> 
>>       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.

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.

>             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?  Most clients that I am aware of use
backwards compatible Client Hello messages indicating support for
TLS 1.0.  (But everything after this single handshake message is
usually pure TLS 1.0 -- SSL/TLS protocol version negotiation makes
sure they highest common protocol version is used.)

Forbidding backwards compatible Client Hello messages makes it a
little bit easier to implement servers in theory, but this does does
not help anyone in real life because virtually all connection attempts
will fail.

> If a server wants to accept older Hello messages, that's its own
> business.

This is not about 'older' Client Hello messages, this is about
backwards compatible Client Hello messages -- old format, but new
content.

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

A backwards compatible Client Hello message does not mean that the
connection actually uses the older protocol.  (And anyway, client
authentication isn't worse in SSL 3.0 than in TLS 1.0; in fact, most
cryptographic defects of SSL 3.0 have been preserved in TLS 1.0.)

>                             But client implementations shouldn't 
> expect that sending older Hello messages are going to make them
> interoperable with servers that advertise STARTTLS. 

They cannot expect interoperability if they support only SSL 3.0 or
even SSL 2.0, but that's not what this is about.  No-one requires
servers to support SSL 3.0 or SSL 2.0; all that is required is support
for backwards compatible Client Hello handshake messages so that it is
possible for clients to tolerate SSL-only servers if they feel like
it.  Backwards compatible Client Hello messages are described in the
TLS RFC.


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