Don't know about neutral dictionary, but simply compressing Cloudflare cert using Google cert, gives an additional 6% using brotli -15.
I would rather have a biased dictionary than none at all :) Cheers, Vlad > On Mar 6, 2017, at 4:38 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > > Seems like you might get some traction with adding www. .com, some DN > fields (CN=, O=, C=), common OIDs, with some OIDs attached to values > (like key usage and signature algorithm). Most of that is relatively > short though. > >> On 7 March 2017 at 11:15, Victor Vasiliev <vasi...@google.com> wrote: >> Hi Vlad, >> >> This is still an open issue: >> https://github.com/ghedo/tls-certificate-compression/issues/2 >> >> The problem here is creating a dictionary that is both neutral with respect >> to >> the certificate's issuing authority, and actually has a noticeable effect. >> So >> far my personal attempts at making such a dictionary have not been very >> successful, but this might change. Even if we get a dictionary, I do not >> expect the effect to be large compared to the effect of just compressing the >> chain in the first place. >> >> -- Victor. >> >>> On Mon, Mar 6, 2017 at 6:32 PM, Vlad Krasnov <v...@cloudflare.com> wrote: >>> >>> 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 <vasi...@google.com> 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 <martin.thom...@gmail.com> >>> 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 <vasi...@google.com> 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/ >>>>> [ GitHub repo: 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 >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
