Hiya, On 08/03/16 01:19, Sean Turner wrote: > 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.
Please figure out what changes if any are needed and let me know. If those are uncontroversial and don't affect interop we can just make 'em. (I'll check the IESG are ok too but that should add more delay.) If (more likely maybe) those are uncontroversial but do affect interop, we should probably do another IETF LC just in case and all going well, I'll just check if the IESG are ok with just going ahead (as I'd expect) of if they want do another IESG review. If those are controversial, then I can formally mark it as being back with the WG and when the WG are ready we can start over with a fresh IETF LC and IESG review. Cheers, S. > > spt > >> Begin forwarded message: >> >> From: Karthikeyan Bhargavan <karthik.bharga...@gmail.com> Subject: >> Re: Cached Info Date: February 23, 2016 at 12:34:31 GMT+9 To: Sean >> Turner <turn...@ieca.com>, Eric Rescorla <e...@rtfm.com>, Martin >> Thomson <martin.thom...@gmail.com>, "Stephen ie>" >> <stephen.farr...@cs.tcd.ie> Cc: Antoine Delignat-Lavaud >> <an...@microsoft.com> >> >> 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 >> > > > > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
