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

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 27 Nov 2016 01:54:37 +0000

Hello,

not sure if this has been discussed before (apologies if it has).

QUIC mandates that certificate chains be gzip compressed in order to reduce the
amount of bytes transmitted during full handshake.

The QUIC crypto document says:

  Any remaining certificates are gzip compressed with a pre-shared dictionary
  that consists of the certificates specified by either of the first two
  methods, and a block of common strings from certificates taken from the
  Alexa top 5000.

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0

Has anyone though about including something like that in TLS 1.3?

Given that certificates usually take up most of the bytes exchanged during a
full handshake it seems this could be useful, but I don't know if in practice
the benefits are worth the added complexity. Thoughts?

Cheers

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Nov 2016 18:03:10 -0800

TLS already contains a certificate caching mechanism (
https://tools.ietf.org/html/rfc7924).

A more general scheme looks like it ought to perform better against new
sites, though I've
also heard some questions about whether the additional complexity tradeoff
is worth it.
If someone wanted to write a certificate compression draft for TLS, this
certainly is something
that would be worth examining. I don't see any reason we would need to
limit/tie it to TLS 1.3
however.

-Ekr

On Sat, Nov 26, 2016 at 5:54 PM, Alessandro Ghedini <[email-masked]>
wrote:

> https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_
> L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Victor Vasiliev <[email-masked]>
Date: Sat, 26 Nov 2016 23:42:20 -0500

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.

  -- Victor.

On Sat, Nov 26, 2016 at 9:03 PM, Eric Rescorla <[email-masked]> wrote:

> On Sat, Nov 26, 2016 at 5:54 PM, Alessandro Ghedini <[email-masked]
> > wrote:
>
>> Hello,
>>
>> https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH
>> d_L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0
>>

---

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 27 Nov 2016 15:13:04 +0000

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

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

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Nov 2016 20:20:00 +0000

> download certificates from CT logs and see how effective the compression is).

My concerned is that any packet size benefit from compressing
certificates with gzip is likely not worth the CPU cost and attack
surface of performing the compression and uncompression.

FWIW, my long-standing practice is to not link the SSL library with
zlib.  I was doing this as a matter of hygiene, long before the
various attacks on (application payload) compression were reported.

-- 
	Viktor.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 Nov 2016 10:36:45 +0100

> Chromium does with QUIC. I also haven't really tested it yet (but at

I guess one could use the certificate type negotiation mechanism from
RFC7250 to negotiate a compressed certificate, instead of a normal one.

That would require registering an ID at:
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

> https://github.com/ghedo/tls-certificate-compression

Have you considered lz4 instead of zlib?

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Tue, 29 Nov 2016 13:56:43 +0100

On Sunday, 27 November 2016 01:54:37 CET Alessandro Ghedini wrote:
> QUIC mandates that certificate chains be gzip compressed in order to reduce
> the amount of bytes transmitted during full handshake.
> 
>   Any remaining certificates are gzip compressed with a pre-shared
> dictionary that consists of the certificates specified by either of the
> first two methods, and a block of common strings from certificates taken
> from the Alexa top 5000.
> 
> full handshake it seems this could be useful, but I don't know if in
> practice the benefits are worth the added complexity. Thoughts?

Decompressing completely untrusted and unverified data directly in the 
security library?

No, I don't think we need more complex code in TLS implementations.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 29 Nov 2016 14:05:21 +0100

> No, I don't think we need more complex code in TLS implementations.

Well, PKIX/X.509 parsing seems to be order of magnitude more complex
than compression :)

regards,
Nikos

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 29 Nov 2016 14:20:53 +0100

> Well, PKIX/X.509 parsing seems to be order of magnitude more complex

I have implemented both at times, so I can confirm that X.509 parsing is
a bit more complex than decompression (with Deflate). The _compression_
is tougher.

Another point which is worth pointing out is that decompression (again
with Deflate, the algorithm inside gzip) works on repeating sequences in
the past 32 kB window, so reliable implementation requires an up to 32 kB
buffer. This won't make RAM-constrained people happy.

	--Thomas Pornin

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Nov 2016 13:28:10 +0000

Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" -- see https://en.wikipedia.org/wiki/Zip_bomb

The risks of uncompressing data sent from a counterparty who has not yet been authenticated, do not outweigh the gains.

	/r$
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz