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

[Viktor Dukhovni]

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

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

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bill Frantz]

On 11/29/16 at 5:28 AM, rs...@akamai.com (Salz, Rich) wrote:


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.


There is a long history of successful attacks on systems through 
zip decompressors.


In general, adding complexity to a security system makes it 
harder to understand, easier to compromise and less secure.


If the problem is that certificates are too big, fix that 
problem at the source.


Cheers - Bill

---
Bill Frantz| Privacy is dead, get over| Periwinkle
(408)356-8506  | it.  | 16345 
Englewood Ave
www.pwpconsult.com |  - Scott McNealy | Los Gatos, 
CA 95032


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Thomas Pornin]

On Tue, Nov 29, 2016 at 02:05:21PM +0100, Nikos Mavrogiannopoulos wrote:
> Well, PKIX/X.509 parsing seems to be order of magnitude more complex
> than compression :)

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nikos Mavrogiannopoulos]

On Tue, 2016-11-29 at 13:56 +0100, Hubert Kario wrote:

> > 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?
> 
> Decompressing completely untrusted and unverified data directly in
> the 
> security library?
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Sunday, 27 November 2016 01:54:37 CET Alessandro Ghedini wrote:
> 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_L2f5LTaDUDwvZ5
> L6g/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?

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

On Sun, Nov 27, 2016 at 03:13:04PM +, Alessandro Ghedini 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 :) ).
> 
> 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).

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alessandro Ghedini]

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

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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 
wrote:

> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alessandro Ghedini]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls