[Top] [All Lists]

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

2001-07-26 14:28:32

Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>:

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

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

           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

Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
* 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>