Re: [TLS] History of extensions

[Nicolas Williams <[e-mail]>]

On Thu, Nov 12, 2009 at 01:50:13AM -0600, 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:

Indeed.

And I should add that the re-negotiation channel binding can be achieved
_without_ ServerHello extensions!  If that means improved odds for
interop, then you should consider it.

How?  Here's two options:

Option 1: All-or-nothing binding (no support negotiation)

 - The client sends a ClientHello extension saying it _will_ add the
   outer connection's client Finished message to the inner connection's
   Finished message PRF inputs, but the extension does not include that
   data;

 - The server either knows the extension or doesn't:

    - If the server knows the extension, it will modify its Finished
      message computations in the same way as the client, and if both
      have the same outer connection's client Finished message at hand,
      then the handshake will succeed, else it will fail (i.e., the
      inner connection's Finished messages will not check out);

    - If the server does NOT know the extension then it will proceed as
      usual and so... will fail to verify the client's Finished message,
      and the client will fail to verify server's Finished message.

Option 2: Secure negotiation (client can securely detect if the server
	  supports binding, and can choose to forego channel binding if
	  the server doesn't)

 - The client sends a ClientHello extension that includes the outer
   connection's client Finished message;

 - The client will add the outer connection's server Finished message to
   the inner connection's _server_ Finished message PRF inputs (but not
   to the inner connection's _client_ Finished message PRF inputs);

 - The server either knows the extension or doesn't:

    - If the server knows the extension, it will modify its Finished
      message computations in the same way as the client, and if both
      have the same outer connection's server Finished message at hand,
      then the handshake will succeed, else it will fail (i.e., the
      inner connection's Finished messages will not check out);

    - If the server does NOT know the extension then it will proceed as
      usual and so... will fail to verify the client's Finished message,
      and the client will fail to verify server's Finished message.

Note that in either case the ClientHello extension is "non-critical" (in
one sense), there's no ServerHello extension, but the client reliably
finds out if the server understood the extension.  There's no reflection
attack.  The server cannot be implemented incorrectly (that is, it can't
parrot something the client sent).

In option (2) the client gets to reliably discover whether the server
supports the extension, but in a way such that the only way that an MITM
can fool the client is if the negotiated cipher suite does not
authenticate the server (if a server cert is used, then the MITM is
out unless the MITM has the private keys to that cert).  But even if
such a cipher suite had been negotiated, the MITM cannot leverage the
client's user cert authentication to authenticate to the server.

In neither option can the MITM get away with stripping the extension
from the client's Hello, nor can the MITM cause the outer connection's
channel bindings data to match on the client and server side.

The nice thing here is that option (2) could be implemented even by
SSLv3 clients and servers (supposing anyone would bother to patch
those).

Nico
--