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 > <mailto:ryan-ietf...@sleevi.com>> wrote: > > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <sank...@cdac.in > <mailto:sank...@cdac.in>> wrote: > > Hello, > > How is Certificate Compression advantageous over tls > cached-info extension? > Only case I can think of is - when the certificate is being > sent for the first time, > it can be compressed. Since the client doesn't have a copy of > the certificate, > cached-info can't be used. Are there more cases where > compression is useful? > >
The authors presented work noting that reducing the certificate size when the client is first talking to a server can be useful to keep the server's first flight into a certain number of packets, useful to avoid hitting congestion control backoff and/or a cap on (reply size / request size) to avoid DDOS amplification attacks, as for QUIC. > 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) -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
