Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

From: [email-masked]
Date: Wed, 03 Oct 2018 05:29:33 -0700

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alessandro Ghedini <[email-masked]>
Date: Wed, 3 Oct 2018 13:36:43 +0100

> 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).

Cheers

---

From: Sean Turner <[email-masked]>
Date: Wed, 3 Oct 2018 13:15:22 -0400

> On Oct 3, 2018, at 08:36, Alessandro Ghedini <[email-masked]> wrote:
> 

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?

spt

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 4 Oct 2018 18:01:24 +0100

> 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