Re: [TLS] History of extensions

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> That is wrong.  The SSLv3 spec has the exact same provisions for
> TLS extensions as the TLSv1.0 and TLSv1.1 specs.
>
> TLS extensions became a standard part of the protocol in TLSv1.2 only.
>
> Compare the specs and you will see.

Very enlightening, it's even more complicated than you said. No wonder
these things don't interoperate quite so well.

Here's what I find:

SSL 3.0 draft-freier-ssl-version3-02.txt

   "In the interests of forward compatibility, it is
   permitted for a client hello message to include
   extra data after the compression methods."

RFC 2246 TLS 1.0 (Jan 1999)

   "In the interests of forward compatibility, it is permitted for a
   client hello message to include extra data after the compression
   methods. This data must be included in the handshake hashes, but
   must otherwise be ignored. This is the only handshake message for
   which this is legal; for all other messages, the amount of data
   in the message must match the description of the message precisely."

RFC 3546 TLS Extensions (June 2003)
   Updates 2246 (TLS 1.0)

   "The extensions described in this document may be used by TLS 1.0
   clients and TLS 1.0 servers.  The extensions are designed to be
   backwards compatible - meaning that TLS 1.0 clients that support the
   extensions can talk to TLS 1.0 servers that do not support the
   extensions, and vice versa."
   "Note that the extended server hello message is only sent in response
   to an extended client hello message.  This prevents the possibility
   that the extended server hello message could "break" existing TLS 1.0
   clients"
   "The extended server hello message format MAY be sent in place of the
   server hello message when the client has requested extended
   functionality via the extended client hello message"

RFC 4346 TLS 1.1 (April 2006)

   "In the interests of forward
   compatibility, it is permitted that a client hello message include
   extra data after the compression methods. This data MUST be included
   in the handshake hashes, but must otherwise be ignored. This is the
   only handshake message for which this is legal; for all other
   messages, the amount of data in the message MUST match the
   description of the message precisely.

RFC 4366 TLS Extensions (April 2006)
   Updates 4346 (TLS 1.1)
   "The document therefore updates TLS 1.0 [TLS] and TLS 1.1"
   "The extended server hello message format MAY be sent in place of the
   server hello message when the client has requested extended
   functionality via the extended client hello message"

RFC 5246 TLS 1.2

   "Clients MAY request extended functionality from servers by sending
   data in the extensions field.  The actual "Extension" format is
   defined in Section 7.4.1.4."
   "[server] A list of extensions.  Note that only extensions offered
   by the client can appear in the server's list."

------
My interpretation:

SSL 3.0  Allows room at the end of Client Hello for extra data.
         Is silent on extra data after Server Hello.
         No standard defines anything to be passed here.

TLS 1.0  Allows room at the end of Client Hello for extra data
         Forbids extra data after Server Hello.
         Possibly went four years with no extensions defined,
         so early implementations were untested in this.

June 2003

RFC 3546 Uses room defined in TLS 1.0 to grow ClientHello into
         ExtendedClientHello.
         Defines a new ExtendedServerHello message without assigning
         it a new HandshakeType. This is probably OK. SSL proxying
         and monitoring may have been confused by this contradiction
         of the spec with no version number bump.

TLS 1.1  Reiterates that only ClientHello can have extra data.
         No provision for ExtendedServerHello.

RFC 4366 Updates TLS 1.0 and 1.1 to re-allow extensions.
         This was simultaneous to 1.1 spec, so just an update.

TLS 1.2  Defines extensions as part of the main TLS spec.

------
Conclusions:

Nothing defines extensions for SSL 3.0, how such servers will react when
sent extra ClientHello data is somewhat unpredictable.

Perfectly-conforming implmentations since spec of Jan 1999 should, in
theory, not be broken.

In practice, TLS server implementations designed before about 2004
probably had no compliant clients with which to test that would send any
data after the traditional ClientHello. Such systems probably shipped
for quite some time afterwards. For example, all pre-Vista Windows OS's
may be in this category based on design date.

There are a large number of TLS implementations that are not currently
extension-aware which will have to retrofit at least primitive support
in order to benefit from this security fix.

- Marsh