Subject: [ietf-tls] Re: London

From: Bodo Moeller <[email-masked]>
Date: Fri, 13 Jul 2001 11:30:35 +0200

On Thu, Jul 12, 2001 at 12:25:28PM -0700, Joseph Hui wrote:

> Maybe now it's a good time to bring up an issue of compatibility
> that may cause grief during the dns_name roll-out: 
> 
>    dsn_name-server     : dns_name-browser,     works;
>    dns_name-server     : non-dns_name-browser, doesn't work;
>    non-dns_name-server : dns_name-browser,     doesn't work;
>    non-dns_name-server : non-dns_name-browser, doesn't work.

This is misleading.  SSL 3.0 and TLS 1.0 servers are required to
ignore extra data at the end of the ClientHello message, and obviously
non-dns_name servers would only be used in situations where the
dns_name extension is not needed (i.e., no name-based virtual
hosting).  Thus the only configuration that is problematic is when a
server requires dns_name, but the client does not support it.  This is
similar to the HTTP "Host" header situation some time ago.

A more important compatibility issue has not been mentioned yet,
as far as I know:

TLS extensions can only be used in SSL 3.0 and TLS 1.0 ClientHello
messages, not in SSL 2.0 CLIENT-HELLO messages.  While it is time to
give up the actual SSL 2.0 protocol, the SSL 2.0 CLIENT-HELLO format
still play an important role for protocol version negotiation, and
handshakes usually start using this format.  Clients still cannot rely
on TLS 1.0 being available on all servers, so they must allow for SSL
3.0 to be negotiated as well (and sometimes even SSL 2.0, but I
wouldn't mind giving this up).  In theory, such protocol version
negotiation is no problem -- set client_version to { 0x03, 0x01 }
(= TLS 1.0) in a SSL 3.0 ClientHello (the main difference to a TLS 1.0
ClientHello is the 'version' value in the record header).  In
practice, many buggy servers handle such ClientHello messages
incorrectly, confusing the client_version value (highest protocol
version supported by the client) with the record header version value
(protocol version tolerated by the client), or checking for the wrong
version number in the encrypted PreMasterSecret.

I predict that this will cause more interoperability problems than the
actual TLS extensions.  Ignoring some extra data is not difficult, but
the details of protocol version negotiation are apparently easy to get
wrong -- we only can rely on it to work quite well when using
SSL 2.0 CLIENT-HELLO messages.

-- 
Bodo Möller <[email-masked]>
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

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]