Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt

[Nicolas Williams <[e-mail]>]

On Fri, Nov 13, 2009 at 02:28:53PM -0500, Robert Dugal wrote:
> A co-worker an I have been discussing the draft and have some concerns
> about sending client and server verify_data in the extension.
> 
> In the ClientHello, the client sends the verify_data from the client's
> previous Finish message as the renegotiated_connection data.
> 
> In the ServerHello, the server sends both the cient's verify_data and
> the server's verify_data.
> 
> This data is not normally sent in the clear and I am wondering if this
> will provide additional data that can be used to mount some other form
> of attack .

See:

draft-altman-tls-channel-bindings-07.txt

which addresses your concern.

> The only reason we are sending any data at all is to prove that the
> renegotiation is bound to a previous handshake, so why not bind it with
> some data that is on the wire and visible to everyone?

One of my counter-proposals, which I ask to be considered if the use of
extensions is problematic for interop reasons, is to add the outer/old
connection's client Finished message as one more input in the inner/new
connection's Finished message verify_data computation (see post to
[e-mail] with message-ID <[e-mail]>.

The rationale for that proposal is not that Finished message verify_data
is sensitive (it is not), but that the use of extensions may be harmful
to interop (and if that's not the case, then that proposal is to be
ignored).

> One possability is to use the client and server randoms as the
> renegotiated_connection data.  This data is sent as plaintext on the
> wire so it reveals nothing the attacker doesn't already know.

I explained why that doesn't work in a post with message-ID
<[e-mail]> posted on Thu, 5 Nov 2009 11:13:08
-0600 (subject: Re: [TLS] TLS renegotiation issue).

> Another alternative could be to use the client's encrypted Finish
> message rather than the verify_data from Client's Finish message, and
> server's encrypted Finish message.

See:

draft-altman-tls-channel-bindings-07.txt

Nico
--