Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3

From: Victor Vasiliev <[email-masked]>
Date: Mon, 5 Dec 2016 18:13:56 -0500

On Sun, Nov 27, 2016 at 10:13 AM, Alessandro Ghedini <[email-masked]>
 wrote:

> On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> > I am currently trying to figure out how much of QUIC certificate
> > compression can be adapted to work with TLS.  I will submit a draft as
> soon
> > as I have a working prototype.
>
> FWIW I too have started working on a prototype for gzip compressing
> certificates
> based on BoringSSL:
> https://github.com/ghedo/boringssl/tree/cert_compress
>
> It's not complete yet and I only implemented compression so far based on
> what
> Chromium does with QUIC. I also haven't really tested it yet (but at least
> it
> builds AFAICT :) ).
>
>
This looks promising!  I am currently working on figuring out a better
pre-shared dictionary
(based on CT logs analysis) so I don't have that much code for the actual
TLS parts.

> I'd like to do some tests as well to measure the benefits of this (e.g.
> download certificates from CT logs and see how effective the compression
> is).
>
>
I am using CT logs as a reference too.

> I also started working on a draft for gzip compression of certificates at:
> https://github.com/ghedo/tls-certificate-compression
>
> Or that's the current scope anyway. Maybe it would also make sense to
> include
> the full QUIC certificate caching part, but I didn't want to duplicate
> RFC7924.
>
> My intention would be to use gzip-compressed certs on first connect, and
> then
> use RFC7924 for consecutive handshakes.
>
>
My plan was to start with a zlib-based compression, and then introduce some
more efficient algorithm as a second step.  I've been looking into the
alternatives,
but I'd have to actually finish the dictionary refresh before doing any
evaluation.

RFC 7924 is another good place to start.  There are multiple improvements
to it
that I have in mind, but it would probably be reasonable to begin by
actually getting
RFC 7924 support into the common implementations.

> The text is not complete and I haven't submitted it yet, though it would be
> nice if we could work on the same draft together, in order to avoid
> duplicating
> work (I can give you or anyone interested commit access to the repo).
>
> Cheers
>

I would be happy to collaborate on the draft!  The TLS 1.2 story should be
relatively
straightforward, but with TLS 1.3 Certificate message format we'd have to
figure out
the correct layering.

  -- Victor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 5 Dec 2016 23:25:40 +0000

On Mon, Dec 05, 2016 at 06:13:56PM -0500, Victor Vasiliev wrote:

> pre-shared dictionary (based on CT logs analysis) so I don't have that
> much code for the actual TLS parts.

What is the likelihood that a dictionary that is good today will
continue to be good 10+ years from now?  Presumably, an effective
dictionary is strongly tied to the current list of popular issuer
DNs, and the list of popular issuers may well change significantly
over the lifetime of the protocol.

-- 
	Viktor.

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 5 Dec 2016 19:36:18 -0500

The intent is to make it agnostic of specific common issuers.  There are a
plenty of common strings which are not going to change for a while.  OIDs
are a
good example (some of the OIDs are quite huge!), as are the common TLDs,
"https://", etc.  Some of them will, of course, become outdated as
technology
evolves (I suspect we might see less of, say, sha256WithRsaEncryption OID
5-10
years from now, and more of whatever the crypto trend of the day is), but we
can just make a new one and assign a different compression algorithm ID to
it,
which should scale reasonably well given the speed at which TLS evolves.

On Mon, Dec 5, 2016 at 6:25 PM, Viktor Dukhovni <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>