Re: [TLS] History of extensions

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> 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."

I would suggest the following document for SSLv3 from 18-Nov-1996:

http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

   Forward compatibility note:
                  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.

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


I think it is OK to encourage interoperability with ExtendenClientHello
and ExtendendServerHello in order to implement Eric's proposal for
the TLS extension Renegotiation_Info.  ClientHello extensibility
has been in the spec for very long, and really is not that much
to implement.

I would appreciate if Eric's draft would precisely describe
what exact elements of TLS extension (rfc4366 or what got integrated
into rfc5246) is necessary to implement this draft.
(ExtendenClientHello, ExtendendServerHello, correct hashing of
handshake message, creation and parsing of extension_data).

-Martin