On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin <david...@chromium.org> wrote:
> On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk <bka...@akamai.com> wrote: > >> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >> >> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <ryan-ietf...@sleevi.com> >> wrote: >> >> Does cached-info not represent a privacy info-leak by disclosing past >> sessions prior to authenticating the new session? Versus compression, which >> limits it to the session and thus reveals no new/additional information. >> That was certainly true for TLS1.2 >> >> >> This will also be true in TLS 1.3, even with encrypted certificates >> because (hopefully) they >> will be a lot smaller. Though you could of course pad out to the same >> size :) >> >> >> The elephant in the room being that an attacker watching the network can >> replay the observed ClientHello but using its own KeyShare and read the >> resulting encrypted certificate reply. (h/t davidben) >> > > (Supposing that the server is a traditional server that accepts multiple > requests and does not select the certificate based on external factors in > the transport or elsewhere, which means you're selecting by things not > covered by TLS's transcript.) > > Also, while one could compressed pad up to uncompressed length and make > compression useless, hiding whether your certificate was compressed is not > a plausible goal. More plausible is hiding which certificate was selected. > > Without compression, your certificates still have different lengths, so > you would need to pad up to max(certificate_message(cert) for cert in > certs) anyway, where certs is all identities your particular server wishes > to make indistinguishable. Maybe chunk up to a boundary beyond that if you > want. > > With compression, you pad up to max(compress(certificate_message(cert) > for cert in certs). Maybe chunk up to a boundary beyond that if you want. > (Packet boundary for the QUIC use case?) This means you're now bound by > your worst cert rather than your selected cert, but one could still expect > a size win. > > This is, of course, all assuming your server setup is somehow such that > the above pachyderm doesn't apply. > Sorry, yes, I should have mentioned this, especially as I just made the same point to someone else the other day. I think there are two threat models here: 1. Active attacker 2. Passive attacker. As you indicate the active attacker can elicit the server's certificate by replaying CH with his own KeyShare (this is part of what makes SNI encryption so hard). For a passive attacker, as David suggests, you can hide which cert was selected by padding up to the largest cert (whether the cert was compressed or not). That may or may not be valuable depending on the scenario [for instance in WebRTC]. As you say, I don't think you can hide the cache hit even from a passive attacker because then you would need to pad up to an unreasonable amount. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
