[TLS] Fwd: Cached Info

[Sean Turner <[e-mail]>]

All,

The cached-info draft got all the way to the IESG and then we receive a couple of comments that require we bring the draft back to the WG to discuss.

spt

> Begin forwarded message:
> 
> From: Karthikeyan Bhargavan <[e-mail]>
> Subject: Re: Cached Info
> Date: February 23, 2016 at 12:34:31 GMT+9
> To: Sean Turner <[e-mail]>, Eric Rescorla <[e-mail]>, Martin Thomson <[e-mail]>, "Stephen ie>" <[e-mail]>
> Cc: Antoine Delignat-Lavaud <[e-mail]>
> 
> Some corrections:
> 
> Dear All,
> 
> I took a quick look at cached-info at Ekr’ prodding, who was worried about key synchronization-style attacks (Ekr’s original email is a the bottom of this email.)
> My conclusion is that the use of a 4-byte hash is unnecessarily fragile.
> The attacks are not super-serious, but the following scenario looks bad.
> Maybe I got something wrong about the spec, so do tell me if I did.
> 
> Suppose that the client uses client certificates (or channelID/token binding) to login to all websites.
> The client’s authentication credential is bound to the current handshake transcript.
> If the transcript does not contain the server certificate, then a malicious server may be able
> to forward a credential sent by the client to the malicious server to a different server.
> This kind of credential forwarding attack enables certain kinds of impersonation (see Triple Handshake)
> 
> In Cached-Info, the transcript includes a 32-bit hash of the certificate and some signature or RSA encryption that uses the certificate signing/encryption key.
> To mount the attack described above, the attacker would first need to find a certificate that collides with the honest server certificate hash.
> You can imagine the attacker generating 2^32 self-signed certificates until the collision is found, this is not hard.
> Next, the attacker still has to match the parts of the transcript that use the server’s public key (if any).
> The client could maybe choose the public key to match that of the server, or carefully choose the RSA signing key to create a signature value that matches that of the real server etc.
> There may be other attacks where the attacker uses a static ECDH ciphersuite, and so does not need to sign anything.
> 
> So now, the honest client C connects to malicious server M that has a self-signed cert (for M).
> C accepts the cert (for M) and agrees to use certificate/token-bound authentication at M.
> M can then forward the credential and signature to S, which will accept it.
> M would not control the keys between M and S (since it used S’s public key.)
> But if C is using a browser, then C’s window is at M’s origin, so M can inject 
> data into the connection which will then be forwarded to S, as if the authenticated user C intended to send it to M.
> 
> Perhaps the above attack is not very worrisome to some people, but the silly
> bit is that accepting this risk is completely unnecessary. The client and 
> server could simply use the full SHA-256 hash for the certificate and the
> client would have a hard time creating a colliding certificate.
> 
> Best,
> Karthik


> —————
> Ekr’s original email
> ————————
> 
> Folks,
> 
> I've been thinking over the cached-info draft, and I'm not convinced
> that the security analysis is right.
> 
> In the current design, the client sends a truncated 32-bit hash
> of what it believes the server's certificate is. If that matches
> the server's certificate, then the server echoes that truncated
> hash (if I'm reading it correctly).
> 
> The security considerations section claims:
> 
>    The use of the cached info extension allows the server to send
>    significantly smaller TLS messages.  Consequently, these omitted
>    parts of the messages are not included in the transcript of the
>    handshake in the TLS Finish message.  However, since the client and
>    the server communicate the hash values of the cached data in the
>    initial handshake messages the fingerprints are included in the TLS
>    Finish message.
> 
> But this isn't correct with a short hash, since you're not strongly
> binding the hash into the handshake. And elsewhere the text claims
> that the hash isn't relevant:
> 
>    If an attacker
>    injects an incorrect fingerprint then two outcomes are possible: (1)
>    The fingerprint does not relate to any cached state and the server
>    has to fall back to a full exchange. (2) If the attacker manages to
>    inject a fingerprint that refers to data the client has not cached
>    then the exchange will fail later when the client continues with the
>    handshake and aims to verify the digital signature.  The signature
>    verification will fail since the public key cached by the client will
>    not correspond to the private key that was used by server to sign the
>    message.
> 
> I think this is closer to the truth. But consider the case where
> an attacker convinces the client to accept a certificate for
> attacker.com <http://attacker.com/> but with victim.com <http://victim.com/>'s public key that *also*
> hash the same fingerprint as victim.com <http://victim.com/>'s certificate. In that case,
> you could end up with a UKS between the client and victim.com <http://victim.com/>
> (where the client thinks he's talking to attacker.com <http://attacker.com/>). What prevents
> this (I believe) is the text in Security Considerations:
> 
>    Clients MUST ensure that they only cache information from legitimate
>    sources.  For example, when the client populates the cache from a TLS
>    exchange then it must only cache information after the successful
>    completion of a TLS exchange to ensure that an attacker does not
>    inject incorrect information into the cache.  Failure to do so allows
>    for man-in-the-middle attacks.
> 
> If followed, this will stop the client from accepting attacker.com <http://attacker.com/>'s
> bogus cert (because he doesn't have the private key). Note, however, that
> you have to follow it strictly. For instance, if you cache after
> False Start, then you are vulnerable to this attack. Also, these
> instructions seem really counterintuitive, because naively you
> would expect to just be able to validate the server's cert and
> store the hash once it had been validated. I also note that this
> advice was in the draft in -19 when the full hash was used.
> 
> To be honest, I'm not entirely convinced that this advice is sufficient,
> but I don't have a complete analysis either way. However, I do think it's
> clear that the text in the draft is confusing.
> 
> Thoughts?
> -Ekr
>