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. David
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
