Re: [TLS] simplistic renego protection

[Eric Rescorla <[e-mail]>]

At Mon, 16 Nov 2009 01:36:55 +0100 (MET),
Martin Rex wrote:
> 
> The most simplistic approch to renego protection is
> 
>    1. the client signals that it is patched through a fake
>       ciphersuite ID in each ClientHello
> 
>    2. the client only supports secure renegotiation and
>       secure renegotiation is specified to change the definition
>       of the handshake message hash for renegotiation handshakes
>       to include the verify_data of the client.finished and
>       server.finished after the ServerHello.
> 
> Everything else is options for vendors and users.

This is an interesting suggestion, but I think it has some problematic
aspects.

As has been noted several times, if the client desires to guarantee
that it does not form connections to unpatched servers, then servers
need to behave differently only on the initial connection. Your
proposal doesn't accomodate this.

Obviously this could be fixed--the natural approach is to modify
the server's Finished even on the initial negotiation, but this
requires conditional behavior in the Finished processor, which
is sort of distressing. The problem becomes even more complicated
when we consider resumption. 

We could use other mechanisms, such as ServerRandom signalling, but
we're now at the point where we're generating a lame version of
extension signalling using other mechanisms. Absent some evidence that
there is a real SSLv3 compatibility issue, I'm not sure why that's a
good idea.

On an aesthetic level, the TLS handshake hashes are just that,
handshake hashes. Injecting new data into that computation doesn't
strike me as really that architecturally fantastic an idea. If we
were to go down that road, I suspect that Rob Dugal's suggestion
of just continuing the handshake hashes would be superior.

-Ekr