Hi Victor, Have you considered creating a common dictionary, similarly to what SPDY did for header compression?
Cheers, Vlad > On Mar 6, 2017, at 3:23 PM, Victor Vasiliev <[email protected]> wrote: > > Hi Martin, > > I've measured the effect of compression on a corpus of popular website > certificate chains I had lying around (Alexa Top 100k from a few years ago), > and the effect seems to be about -30% of size at the median and -48% at 95th > percentile (with Brotli, subtract 3-5% for zlib). > > I think the most dramatic effect from the compression is observed for the > certificates with a lot of SNI values, which is not uncommon. > > -- Victor. > > On Mon, Mar 6, 2017 at 6:06 PM, Martin Thomson <[email protected] > <mailto:[email protected]>> wrote: > Hi Victor, > > Do you have any evidence to suggest that this reduces size in any > meaningful way? Certificates tend to include both repetitious values > (OIDs), and non-repetitious values (keys). > > On 7 March 2017 at 09:58, Victor Vasiliev <[email protected] > <mailto:[email protected]>> wrote: > > Certificate compression has been discussed on this list briefly before, and > > there was some interest in at least considering a draft for it. The draft > > now > > exists (co-authored by Alessandro and myself), and it can be found at: > > > > https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/ > > <https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/> > > [ GitHub repo: https://github.com/ghedo/tls-certificate-compression > > <https://github.com/ghedo/tls-certificate-compression> ] > > > > The proposed scheme allows a client and a server to negotiate a compression > > algorithm for the server certificate message. The scheme is purely opt-in > > on > > both sides. The current version of the draft defines zlib and Brotli > > compression, both of which are well-specified formats with an existing > > deployment experience. > > > > There are multiple motivations to compress certificates. The first one is > > that > > the smaller they are, the faster they arrive (both due to the transfer time > > and > > a decreased chance of packet loss). > > > > The second, and more interesting one, is that having small certificates is > > important for QUIC in order to achieve 1-RTT handshakes while limiting the > > opportunities for amplification attacks. Currently, TLS 1.3 over TCP > > without > > client auth looks like this: > > > > Round trip 1: client sends SYN, server sends SYN ACK > > Here, the server provides its own random value which client will > > have to echo in the future. > > Round trip 2: client sends ACK, ClientHello, server sends > > ServerHello...Finished > > Here, ACK confirms to server that the client can receive packets and is > > not > > just spoofing its source address. Server can send the entire > > ServerHello to > > Finished flight. > > > > In QUIC, we are trying to merge those two rounds into one. The problem, > > however, is that the ClientHello is one packet, and ServerHello...Finished > > can > > span multiple packets, meaning that this could be used as an amplification > > attack vector since the client's address is not yet authenticated at this > > point. > > In order to address this, the server has to limit the number of packets it > > sends > > during the first flight (i.e. ServerHello...Finished flight). Since > > certificates make up the majority of data in that flight, making them > > smaller > > can push them under the limit and save a round-trip. > > > > Cheers, > > Victor. > > > > _______________________________________________ > > TLS mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
