On Wed, Apr 5, 2017 at 10:45 AM, Eric Rescorla <[email protected]> wrote:
> > > On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin <[email protected]> > wrote: > >> On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk <[email protected]> wrote: >> >>> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >>> >>> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <[email protected]> >>> 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). > Or of course, if we had an SNI encryption mechanism that tied to KeyShare. -Ekr > > 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
