Re: [TLS] History of extensions

[Eric Rescorla <[e-mail]>]

At Thu, 12 Nov 2009 14:38:47 -0600,
Nicolas Williams wrote:
> 
> On Thu, Nov 12, 2009 at 09:36:09PM +0100, Martin Rex wrote:
> > Backwards signaling server->client that the server is updated is
> > a little more difficult because one would have to repurpose an element
> > of the ServerHello.  If there really are SSL implemenations that fill
> > the unix_gmt_time with all random data (instead of just fuzzing the
> > lower bits of it), then that part requires a less "pure" approach.
> > 
> > Maybe by confiscating a currently unused bit of the more tightly
> > controlled value ranges of other members of the ServerHello handshake
> > message (server_version.major, cipher_suite or compression_method).
> 
> The whole point of my post was to point out that there is a way to do
> the server->client signaling without changing a single bit on the wire
> -- just the Finished message computations.
> 
> Interestingly, that approach could even be used on initial connections
> to detect if the server will support secure re-negotiation _before_ the
> client ever tries it.

I don't see that. AFAICT both your options involve the client generating a 
hello extension, so this does affect the bits on the wire. Obviously
there are approaches which don't require that, but they don't provide
detection of server capabilities on initial negotiation. By contrast
your message of 1854 doesn't allow the client to probe the server 
AFAICT.

-Ekr