On Wed, Oct 03, 2018 at 01:15:22PM -0400, Sean Turner wrote: > > > > On Oct 3, 2018, at 08:36, Alessandro Ghedini <alessan...@ghedini.me> wrote: > > > > On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-dra...@ietf.org wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Transport Layer Security WG of the IETF. > >> > >> Title : TLS Certificate Compression > >> Authors : Alessandro Ghedini > >> Victor Vasiliev > >> Filename : draft-ietf-tls-certificate-compression-04.txt > >> Pages : 7 > >> Date : 2018-10-03 > >> > >> Abstract: > >> In TLS handshakes, certificate chains often take up the majority of > >> the bytes transmitted. > >> > >> This document describes how certificate chains can be compressed to > >> reduce the amount of data transmitted and avoid some round trips. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04 > >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04 > > > > This is just a tiny update with a few small fixes and the addition of the > > early code points assigned by IANA. > > > > In other news, Chrome landed support for certificate compression in canary > > back in July, and Cloudflare deployed support on its edge servers a few > > weeks ago. > > > > The data we've seen on the Cloudflare side looks quite promising so far, > > although I haven't had the time to do a full analysis yet. We are seeing > > reductions in certificates sizes between 1.5-2 KB for both ECDSA and RSA > > (meaning a full QUIC packet if not more), with average compressed size > > hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA. > > > > The only remaining open issue is the potential attack illustrated by Subodh > > a few months ago > > https://www.ietf.org/mail-archive/web/tls/current/msg25851.html > > > >> From the reaction on that mailing list discussion, and from talking to > >> people > > at the last IETF, it seems to me that the attack doesn't appear to worry > > people > > much and that there isn't much interest in fixing it. Though I thought I'd > > mention it again to see if people have anything to add to it, and see if we > > can agree on whether we should do anything about it. > > > > Other than that it looks like the draft is in a pretty good shape at this > > point, > > so it'd be nice to have some additional review, and then see if it can > > proceed > > to the next step (which I think would be WGLC). > > Alessandro - thanks for this update. > > WG - I’d like to echo Alessandro request for reviews. If this outstanding > WG item is not resolved before IETF103 we will discuss the outstanding issue > there, and barring any other major issues we are planning to WGLC the draft > after IETF103. > > One question: There was some discussion earlier about dictionaries. Are > dictionaries being used in the current deployments?
No, neither Chrome nor Cloudflare are using dictionaries. Something I forgot to mention in my previous email is that the numbers are for plain brotli compression, so without dictionary. Cheers _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
