Subject: [TLS] Fwd: Cached Info

From: Sean Turner <[email-masked]>
Date: Tue, 8 Mar 2016 10:19:59 +0900

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 <[email-masked]>
> Subject: Re: Cached Info
> Date: February 23, 2016 at 12:34:31 GMT+9
> To: Sean Turner <[email-masked]>, Eric Rescorla <[email-masked]>, Martin Thomson <[email-masked]>, "Stephen ie>" <[email-masked]>
> Cc: Antoine Delignat-Lavaud <[email-masked]>
> 
> 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
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Mar 2016 10:21:18 +0000

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 <[email-masked]> Subject:
>> Re: Cached Info Date: February 23, 2016 at 12:34:31 GMT+9 To: Sean
>> Turner <[email-masked]>, Eric Rescorla <[email-masked]>, Martin
>> Thomson <[email-masked]>, "Stephen ie>"
>> <[email-masked]> Cc: Antoine Delignat-Lavaud
>> <[email-masked]>
>> 
>> 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).
>> 
>> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 Mar 2016 15:16:03 +0100

Hi all,

in the off-list conversation I have also provided my remarks on the
raised issues.

Here is what I said:

-----------------

Thanks for spending the time to look at the document.

There were indeed concerns about the length of the hash in the working
group and, as you said, there was specific attack raised.

It is true that an attacker (or someone else) can create a certificate
that matches the hash of the certificate used by some other site,
particularly when the hash size is very small (4 bytes in our case).

It appears to me that the vulnerability described below assumes that the
client is somehow tricked into accepting the wrong certificate.

The client stores the hash of the obtained certificate locally after
completing a full handshake with the server. As such, it has to store
the server identity together with the hash.

This cache then has to be populated with the certificate provided by the
adversary.

The client then has to pick the wrong certificate, which matches the
fingerprint.

Such a scenario can indeed happen if the client TLS implementation does
a lookup of the certificate based on the hash alone rather than taking
the server identity into account.

In the other attack that Karthik described the client has to connect to
the malicious server and then that server would relay the messages to an
honest server and the signatures from the client would have to correctly
verify. I am missing a few assumptions about what else needs to go wrong
for this attack to work. Getting the honest server to just accept
relayed client certificate and a signature requires more than the TLS
Cached Info extension

Regardless of the details I understand the concerns. There is indeed an
additional level of brittleness with the introduction of the shortened
hashes. While they consume less bandwidth over the wire (which is nice)
they require a careful implementation.

-----------------

In a nutshell, while I do not believe that the attack described is
realistic I am sensitive to the problem of creating brittle code.

If it is OK for the working group then I would like to revert back to
the previous version of the draft where we use the longer hash.

Ciao
Hannes

On 03/08/2016 02:19 AM, 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.
> 
> spt
> 
>> Begin forwarded message:
>>
>> *From: *Karthikeyan Bhargavan <[email-masked]
>> <mailto:[email-masked]>>
>> *Subject: **Re: Cached Info*
>> *Date: *February 23, 2016 at 12:34:31 GMT+9
>> *To: *Sean Turner <[email-masked] <mailto:[email-masked]>>, Eric
>> Rescorla <[email-masked] <mailto:[email-masked]>>, Martin Thomson
>> <[email-masked] <mailto:[email-masked]>>, "Stephen
>> ie>" <[email-masked] <mailto:[email-masked]>>
>> *Cc: *Antoine Delignat-Lavaud <[email-masked]
>> <mailto:[email-masked]>>
>>
>> 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.)
>> 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.
>> 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.
>> data into the connection which will then be forwarded to S, as if the
>> authenticated user C intended to send it to M.
>>
>> <http://victim.com/>'s public key that *also*
>> <http://attacker.com/>'s
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Anirudh Ramachandran <[email-masked]>
Date: Thu, 10 Mar 2016 12:11:08 -0800

Since this is being discussed, I had an unrelated comment about the
following wording:

The draft says in Section 4:

   By returning the "cached_info" extension the server indicates that it
supports the
   cached info types.  For each indicated cached info type the server
   MUST alter the transmission of respective payloads, according to the
   rules outlined with each type

The 'MUST' is likely to indicate to the client that a match has been found,
which is useful. However, most SSL implementations (e.g,. OpenSSL) create
and process messages one state at a time. The same buffer is reused for
each handshake message, which means that only after the ServerHello message
is constructed and sent is the Certificate message be constructed. If one
were to follow the draft, there are two options – either hold back the
ServerHello until the Certificate message is constructed and hashed, or
early-construct the Certificate message while assembling the ServerHello.
Both options introduce complications in implementation because the draft is
asking to hash data from a later state during ServerHello.

An alternative might be to use the ServerHello cached_info extension merely
to indicate support of the extension, and indicate the cached info hit/miss
during the Certificate message. This can already be done implicitly — If
the Certificate message is of length exactly 4 bytes, the client looks up
its CachedInformation store using the tuple <servername, server-supplied
hash> to retrieve the correct cached Certificate message (a miss indicates
a protocol error). We believe this lookup is needed anyway since a client
might have multiple certificates stored per servername (e.g., both EC and
RSA certs) and will anyways need to a lookup to figure out which
Certificate should be picked.

Was this issue discussed, or perhaps my read of the draft is wrong?

Thanks,
Anirudh

On Wed, Mar 9, 2016 at 6:16 AM, Hannes Tschofenig <[email-masked]
> wrote:

---

From: Sean Turner <[email-masked]>
Date: Mon, 21 Mar 2016 10:48:53 -0400

On Mar 09, 2016, at 09:16, Hannes Tschofenig <[email-masked]> wrote:

…snip

Hannes,

It’s been 10 days and there’s been no objections so I think it’s safe to revert back to the long hash.

spt