Re: [TLS] MITM Attacks on Client Authentication after Resumption

[[e-mail] (Martin Rex)]

I've just started wondering:  Is the real problem acutally
worse than described, and will changing the Master Secret computation
actually _not_ fix the renegotiation problem?

I wrote:
> 
> The original renegotiation problem and the newly describe session resumption
> problem are very similar:  flawed assumptions about a cryptographic binding
> that doesn't exist.  But until you write down the exact properties and
> think about it, you may not notice the problem.  As soon as you write it
> down, the problem becomes obvious.
> 
> The abbreviated TLS handshake authenticates only the MasterSecret.
> But the MasterSecret is derived exclusively from ClientHello.random,
> ServerHello.random and the keyExchange transform, there is no cryptographic
> binding to any identities that are authenticated during the TLS handshake.
> 
> 
> So the fix of the abbreviated TLS handshake needs to account for the
> (re-)authentication of the identities of the original full handshake,
> either by modifying the MasterSecret computation or by authenticating
> the original full handshake during the abbreviated TLS handshake
> through a TLS extension similar to how the renegotiation_info extension
> does this in the renegotiation handshake.


The only "non-static" data covered by the Finished handshake messages of
the abbbreviated TLS handshake (i.e. that goes into the renegotiation_info
of the resumed TLS handshake are):

    ClientHello.random
    ServerHello.random
    ClientHello.session_id == ServerHello.session_id

In particular, there is *NO* dependency on the MasterSecret, so
the attack by an MitM should be possible, even if the MasterSecrets
differ between the two sessions that are merged (I never had a
requirement in my attack scenario that the MasterSecrets are the
same; in fact I wasn't even aware that it was possible to
create two SSL sessions with identical MasterSecrets & traffic keys
when I described my attack).  The MitM will only have to
decrypt and re-encrypt the data during the original two sessions.

The handshake_message hash does not "see" the encryption, it operates
on the plaintext only.

So it seems to me that changing the MasterSecret computation will
not help.  We need a TLS extension on the abbreviated TLS handshake
that authenticates the original full handshake, such as the
renegotiation_info from that handshake.

-Martin