Re: [TLS] Refactoring client auth/re-key

[Ilari Liusvaara <[e-mail]>]

On Sun, Oct 19, 2014 at 08:57:25AM +0200, Karthikeyan Bhargavan wrote:
> 
> One may argue that the client and server authenticated identities
> (Certificates) do not need to be included in the session hash. This
> would be true for the initial handshake, but not for resumption. One
> use of the TLS 1.2 master secret is as a key for session resumption,
> and the Triple Handshake attack relies on the master secret not being
> bound to the peer’s identity. 

I think this is just wrong. And if it was true, you would have much
much worse problems.


- To defeat the renego fix, you need finished collision.
- To get finished collision, you need MS collision.
- MS collision is already damaging in itself.

If kex is passive-attack secure, MS hashes in kex parameters, exchange
keys, nonces (only needs to be unique across exchange key
offered) and kex result: Then MS collision impiles that kex
parameters, exchange keys and nonces are the same (kex result will be
the same too).

But since kex is passive-attack secure, MS will be unknowable for the
attacker, and any tampering will make handshake fail.

Now, for non-PFS key exchanges, certificates can contain exchange keys.
In practicular, RSA kex server certs do contain exchange key. And
thus under "hash exchange keys", you need to hash it.


In fact, one wants slightly stronger property: Each and every full
handshake computes a fresh MS never before seen, even if peer is
maliscous. But hashing the stuff listed above is sufficient for that,
because each (exchange key, nonce) pair from honest peers will be
unique, forcing the MS computed by those to be different (what
MS maliscous endpoints compute is no consideration).


The reason why one wants to also hash the crypto negotiation is to
avoid downgrade attacks.



-Ilari