[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Keith Moore <moore@xxxxxxxxxx>:
>>> 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 <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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