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 <[email protected]> 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 <[email protected]> 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 <[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]> >> 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]> 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 >>> > [email protected] >>> > 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
