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

[David-Sarah Hopwood <[e-mail]>]

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 .

I can't see a feasible attack as long as the hash function doesn't
reveal information about its input. However, I think you're right to
be concerned; we need input from experienced cryptographers about this.

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

That doesn't have the same security properties. It is possible for two
different sessions to have the same (ClientRandom, ServerRandom) pair.
(Attacker acts as a MITM and forwards client's random to server and
vice-versa.)

The Finished hashes, OTOH, are unique to a session because an attacker
can't force the whole handshake to be identical for two sessions
(well, unless they are talking to themself).

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

That would work.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com