Re: [TLS] Certificate compression draft

Hello, I see your point regarding privacy and complexity arising in cache-info. Should we use compression then instead of cache-info every time ? When should we use cache-info and when should we use compression ? Thanks and Regards, Sankalp Bagaria. On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagari

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 10:45 AM, Eric Rescorla wrote: > > > On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin > wrote: > >> On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: >> >>> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >>> >>> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi >>> wrote: >>>

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin wrote: > On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: > >> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >> >> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi >> wrote: >> >> Does cached-info not represent a privacy info-leak by disclosing pas

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: > On 04/05/2017 09:21 AM, Eric Rescorla wrote: > > On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi > wrote: > > Does cached-info not represent a privacy info-leak by disclosing past > sessions prior to authenticating the new session? Versus compr

Re: [TLS] Certificate compression draft

On 04/05/2017 09:21 AM, Eric Rescorla wrote: > > > On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi > wrote: > > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria > wrote: > > Hello, > > How is Certificate Comp

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi wrote: > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > >> Hello, >> >> How is Certificate Compression advantageous over tls cached-info >> extension? >> Only case I can think of is - when the certificate is being sent for the >> first ti

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > Hello, > > How is Certificate Compression advantageous over tls cached-info extension? > Only case I can think of is - when the certificate is being sent for the > first time, > it can be compressed. Since the client doesn't have a copy of

Re: [TLS] Certificate compression draft

Hello, How is Certificate Compression advantageous over tls cached-info extension? Only case I can think of is - when the certificate is being sent for the first time, it can be compressed. Since the client doesn't have a copy of the certificate, cached-info can't be used. Are there more cases whe

Re: [TLS] Certificate compression draft

On Tue, Mar 21, 2017 at 7:30 PM, Eric Rescorla wrote: > This proposal seems like a reasonable idea. One question I had is what the > point of the "uncompressed length" field is: > >struct { > uint24 uncompressed_length; > opaque compressed_certificate_message<1..2^

Re: [TLS] Certificate compression draft

This proposal seems like a reasonable idea. One question I had is what the point of the "uncompressed length" field is: struct { uint24 uncompressed_length; opaque compressed_certificate_message<1..2^24-1>; } Certificate; I initially thought maybe it was a sa

Re: [TLS] Certificate compression draft

Hi Hannes. Cached-Info is useful, but it can only "compress" if the client has previously seen and cached the server's certificate. AIUI, the purpose of draft-ghedini-tls-certificate-compression is to enable compression even in cases where the client hasn't yet seen the server's certificate.

Re: [TLS] Certificate compression draft

Hi Victor why don't you use RFC 7924: https://tools.ietf.org/html/rfc7924 This provides an even better "compression" ratio. Ciao Hannes On 03/06/2017 11:58 PM, Victor Vasiliev wrote: > Certificate compression has been discussed on this list briefly before, and > there was some interest in at l

Re: [TLS] Certificate compression draft

On 7 March 2017 at 13:32, Viktor Dukhovni wrote: > Fewer WebPKI CAs (which are all trusted) seems like an improvement to me. > Though I doubt that compression efficiency would be a major factor in such > an outcome. Like Ryan, I would rather not create any systemic biases in favour of certain par

Re: [TLS] Certificate compression draft

> On Mar 6, 2017, at 9:13 PM, Ryan Sleevi wrote: > > I can appreciate that sentiment, but you do realize the natural consequence > of that - it creates an incentive structure for the larger CAs to get larger, > by virtue of the compression benefits afforded to them by such a dictionary > maki

Re: [TLS] Certificate compression draft

On Mon, Mar 6, 2017 at 5:37 PM, Vlad Krasnov wrote: > Don't know about neutral dictionary, but simply compressing Cloudflare > cert using Google cert, gives an additional 6% using brotli -15. > > I would rather have a biased dictionary than none at all :) > > Cheers, > Vlad I can appreciate tha

Re: [TLS] Certificate compression draft

Don't know about neutral dictionary, but simply compressing Cloudflare cert using Google cert, gives an additional 6% using brotli -15. I would rather have a biased dictionary than none at all :) Cheers, Vlad > On Mar 6, 2017, at 4:38 PM, Martin Thomson wrote: > > Seems like you might get som

Re: [TLS] Certificate compression draft

Seems like you might get some traction with adding www. .com, some DN fields (CN=, O=, C=), common OIDs, with some OIDs attached to values (like key usage and signature algorithm). Most of that is relatively short though. On 7 March 2017 at 11:15, Victor Vasiliev wrote: > Hi Vlad, > > This is st

Re: [TLS] Certificate compression draft

Hi Victor, Have you considered creating a common dictionary, similarly to what SPDY did for header compression? Cheers, Vlad > On Mar 6, 2017, at 3:23 PM, Victor Vasiliev wrote: > > Hi Martin, > > I've measured the effect of compression on a corpus of popular website > certificate chains I

Re: [TLS] Certificate compression draft

> On Mar 6, 2017, at 6:23 PM, Victor Vasiliev wrote: > > Hi Martin, > > I've measured the effect of compression on a corpus of popular website > certificate chains I had lying around (Alexa Top 100k from a few years ago), > and the effect seems to be about -30% of size at the median and -48% at

Re: [TLS] Certificate compression draft

Hi Victor, Do you have any evidence to suggest that this reduces size in any meaningful way? Certificates tend to include both repetitious values (OIDs), and non-repetitious values (keys). On 7 March 2017 at 09:58, Victor Vasiliev wrote: > Certificate compression has been discussed on this list