Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Watson Ladd]

On Wed, Jun 7, 2017 at 5:43 PM, Dave Garrett  wrote:

> On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote:
> > > Additionally, there's one bit of the spec which I question the need
> for: zlib support. Unless someone can show a legitimate case where zlib
> will consistently and notably outperform brotli, I don't see the point in
> defining it as an option. This is a bran new extension; we don't need
> backwards compatibility here. There's been a general consensus in this WG
> to avoid algorithm agility unless there's a real reason for it, so I
> propose we ditch zlib support and make brotli the default and only
> specified at the start (promoting it to id 0). Should some problem arise in
> the future where we actually need to use a decades old compression
> algorithm, it can be added later. Furthermore, we should probably define a
> pre-defined dictionary for brotli to use here which is based on common
> strings in certificates, rather than its default one for the general web
> (if such a thing is practical to do here). This could boost efficiency here
> and make it even more worth preferring (also likely reducing t
>  he size of said dictionary, as the default one is 120kB).
> >
> > To play devil's advocate, why do suggest we ditch zlib and not Brotli?
> >
> > I just did an experiment using certificate chains for facebook.com
> > (ECDSA) and google.com (RSA).
> >
> [...snip...]
> >
> > As you can see, at level 1, Brotli is easily outperformed by gzip with
> > and without dictionary, at level 6, both are basically the same, and
> > at level 9/Z, Brotli wins by a small margin in terms of file size.
> >
> > However, you need to keep in mind that Brotli has significantly higher
> > cost of compression, both in terms of CPU and memory allocations
> > (>40MB at higher levels), which might be unacceptable in some
> > environments.
> >
> > Don't get me wrong, I'm a big fan of Brotli, but unless we want to
> > squeeze every single byte out of the compression and/or use
> > pre-compressed certificates, then maybe Brotli isn't the best and only
> > choice here?
>
> This is a convincing argument to me. Thanks for the data. Given this
> information, I agree that supporting both algorithms can be helpful here,
> depending on server hardware constraints.
>
> I'm still curious to know if we can potentially create a lightweight
> cert-specific dictionary here that can boost things a bit. Or, is the QUIC
> one largely based on certs too?
>
> As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give
> us any useful gains here over zlib, even with a new dict, I'd be ok with
> not specifying it for use. Your test does show it getting a small win at
> max compression, so that may not be the case. After fiddling with defining
> a new dict, test data against a larger set of certs could be useful.
>

I'm not sure what units we are measuring in here: 222% of what? And what
exactly is wrong with special formats that be much more compact on embedded
devices, or enabling point compression?

If you want root+intermediate+leaf that's 224 bytes of keys and signatures.
Being sparing in extra data can probably have <300 byte chains, without the
CPU overhead of compression at the cost of compatibility.


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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Dave Garrett]

On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote:
> > Additionally, there's one bit of the spec which I question the need for: 
> > zlib support. Unless someone can show a legitimate case where zlib will 
> > consistently and notably outperform brotli, I don't see the point in 
> > defining it as an option. This is a bran new extension; we don't need 
> > backwards compatibility here. There's been a general consensus in this WG 
> > to avoid algorithm agility unless there's a real reason for it, so I 
> > propose we ditch zlib support and make brotli the default and only 
> > specified at the start (promoting it to id 0). Should some problem arise in 
> > the future where we actually need to use a decades old compression 
> > algorithm, it can be added later. Furthermore, we should probably define a 
> > pre-defined dictionary for brotli to use here which is based on common 
> > strings in certificates, rather than its default one for the general web 
> > (if such a thing is practical to do here). This could boost efficiency here 
> > and make it even more worth preferring (also likely reducing t
 he size of said dictionary, as the default one is 120kB).
> 
> To play devil's advocate, why do suggest we ditch zlib and not Brotli?
> 
> I just did an experiment using certificate chains for facebook.com
> (ECDSA) and google.com (RSA).
> 
[...snip...]
> 
> As you can see, at level 1, Brotli is easily outperformed by gzip with
> and without dictionary, at level 6, both are basically the same, and
> at level 9/Z, Brotli wins by a small margin in terms of file size.
> 
> However, you need to keep in mind that Brotli has significantly higher
> cost of compression, both in terms of CPU and memory allocations
> (>40MB at higher levels), which might be unacceptable in some
> environments.
> 
> Don't get me wrong, I'm a big fan of Brotli, but unless we want to
> squeeze every single byte out of the compression and/or use
> pre-compressed certificates, then maybe Brotli isn't the best and only
> choice here?

This is a convincing argument to me. Thanks for the data. Given this 
information, I agree that supporting both algorithms can be helpful here, 
depending on server hardware constraints.

I'm still curious to know if we can potentially create a lightweight 
cert-specific dictionary here that can boost things a bit. Or, is the QUIC one 
largely based on certs too?

As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give us any 
useful gains here over zlib, even with a new dict, I'd be ok with not 
specifying it for use. Your test does show it getting a small win at max 
compression, so that may not be the case. After fiddling with defining a new 
dict, test data against a larger set of certs could be useful.


Dave

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

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Martin Rex]

Ilari Liusvaara wrote:
>On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote:
>> Hi Victor & Alessandro,
>> 
>> I have gone through the draft and I am having a doubt. 
>> 
>>>   The extension only affects the Certificate message from the server.
>>>   It does not change the format of the Certificate message sent by the
>>>   client.
>> 
>> This draft provides a mechanism to compress only the server certificate
>> message, not the client certificate message. I feel client authentication
>> is not performed in HTTPS of web application. But in all other applications
>> (eg. Wireless sensor network) certificate based client authentication is
>> more important. 
>> 
>> So I suggest we should consider compression on client certificate message
>> also.
> 
> Doing client certificate compression would add some complexity, because
> the compression indication currently needs to be external to certificates,
> and there is no place to stick such indication for client certificate.

A TLS extension could do this indication just fine.


ASN.1 DER encoded X.509v3 certificates all have the same first 12 bits.

0x30 0x8*

So sending an indication inband should also be possible.
But a negotiated TLS extension (proposed by client in ClientHello,
confirmed by server in ServerHello) could also change the Certificate PDU
to provide room for a seperate indicator.


-Martin

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

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[David Benjamin]

On Wed, Jun 7, 2017 at 4:29 PM Ilari Liusvaara 
wrote:

> On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote:
> > Hi Victor & Alessandro,
> >
> > I have gone through the draft and I am having a doubt.
> >
> > >   The extension only affects the Certificate message from the server.
> > >   It does not change the format of the Certificate message sent by the
> > >   client.
> >
> > This draft provides a mechanism to compress only the server certificate
> > message, not the client certificate message. I feel client authentication
> > is not performed in HTTPS of web application. But in all other
> applications
> > (eg. Wireless sensor network) certificate based client authentication is
> > more important.
> >
> > So I suggest we should consider compression on client certificate message
> > also.
>
> Doing client certificate compression would add some complexity, because
> the compression indication currently needs to be external to certificates,
> and there is no place to stick such indication for client certificate.
>

There was a proposal somewhere to:

-  Rename Certificate to CompressedCertificate.

- Allocate a new HandshakeType.compressed_certificate, with
contents CompressedCertificate.

- If the client (respectively, server) sends the extension in the
ClientHello (respectively, CertificateRequest), the server (respectively,
client) is allowed to send a CompressedCertificate message instead of
Certificate. The client (respectively, server) dispatches on the message
type when processing.

This is a little unusual of an extension acknowledgement and conflicts
with, say, another extension which tries to play the same game. (Though the
existing scheme needs to be outermost too since it swaps out the spelling
of the CompressedCertificate message.)

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

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Ilari Liusvaara]

On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote:
> Hi Victor & Alessandro,
> 
> I have gone through the draft and I am having a doubt. 
> 
> >   The extension only affects the Certificate message from the server.
> >   It does not change the format of the Certificate message sent by the
> >   client.
> 
> This draft provides a mechanism to compress only the server certificate
> message, not the client certificate message. I feel client authentication
> is not performed in HTTPS of web application. But in all other applications
> (eg. Wireless sensor network) certificate based client authentication is
> more important. 
> 
> So I suggest we should consider compression on client certificate message
> also.

Doing client certificate compression would add some complexity, because
the compression indication currently needs to be external to certificates,
and there is no place to stick such indication for client certificate.


-Ilari

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

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Salz, Rich]

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

> Unless someone can show a legitimate case where zlib will
> consistently and notably outperform brotli, I don't see the point in defining 
> it
> as an option.

As long as the protocol includes space for the encryption algorithm, I agree.

> Furthermore, we should probably define a pre-defined dictionary for
> brotli to use here which is based on common strings in certificates, rather

That could mean that "brotli" is really "brotli+dictionary FOO" which seems 
like a good idea.

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

Re: [TLS] TLS Digest, Vol 155, Issue 13

[Sankalp Bagaria]

>
>
> Message: 3
> Date: Tue, 6 Jun 2017 16:23:24 +0200
> From: Hanno B?ck 
> To: tls@ietf.org
> Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
> Message-ID: <20170606162324.4aee493b@pc1>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, 6 Jun 2017 09:20:03 +0200
> Sean Turner  wrote:
>
> > I appears that we?ve got enough consensus/interest to adopt
> > draft-ghedini-tls-certificate-compression-00 based on the WG session
> > in Chicago and this thread:
>
> Hi,
>
> one aspects brought up in that thread was that there is already RFC
> 7924, which allows certificate caching. There's also AIA, which allows
> a client to fetch intermediate certificates, however as far as I can
> see there's no way for a server to decide whether a client supports AIA.
>
> All of these technologies seem to try to tackle the same problem:
> reduce the burden of transmitting certificates.
>
> I wonder if there should be more a big picture discussion here. If
> clients have a good way of caching certificates - would that mean
> transmitting them is so rare that compressing becomes unnecessary?
>
> Also regarding 7924: I tried to find out what server and client software
> supports that. I didn't find anything. One could see that as an
> indication that it's not a big deal after all. If people are concerned
> about the data wasted by transmitting certificates, I wonder if it
> wouldn't be a more important issue to implement the already existing
> tech that's available instead of inventing new tech.
>
>
> --
> Hanno B?ck
> https://hboeck.de/
>

Dear Hanno,

This issue was raised by me also on April 5, 2017. I got the following
reply.

Regards,
Sankalp Bagaria.

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 the
> certificate,
> cached-info can't be used. Are there more cases where compression is
> useful?
>

Does cached-info not represent a privacy info-leak by disclosing past
sessions prior to authenticating the new session? Versus compression, which
limits it to the session and thus reveals no new/additional information.
That was certainly true for TLS1.2

Is compression not a simpler implementation - given the 'two' hard problems
of computer science (caching, naming, off-by-one)? For example, you'd need
to maintain a per-host cache of certificateinformation to meaningfully make
use of it (... or else you end up with cross-origin state leakage, at least
in the context of a browser, which is a Bad Thing). You would either need
to read that information from stable storage prior to making the connection
(so that you can negotiate the cached info), or you'd need to do a
lazy-path where you index the cached entries and send those as available to
the server, while in parallel beginning to load those entries. If those
entries are corrupted, but used in the connection, the connection will
fail. If those entries are removed during the connection establishment, the
connection will fail.

In short, cached-info represents a much greater degree of complexity and
questionable privacy (both cross-origin and same origin - again, something
relevant for browsers, but perhaps not relevant for others). Let's keep it
simple :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Dave Garrett]

On Wednesday, June 07, 2017 01:38:59 am Raja ashok wrote:
> So I suggest we should consider compression on client certificate message 
> also.

+1

Additionally, there's one bit of the spec which I question the need for: zlib 
support. Unless someone can show a legitimate case where zlib will consistently 
and notably outperform brotli, I don't see the point in defining it as an 
option. This is a bran new extension; we don't need backwards compatibility 
here. There's been a general consensus in this WG to avoid algorithm agility 
unless there's a real reason for it, so I propose we ditch zlib support and 
make brotli the default and only specified at the start (promoting it to id 0). 
Should some problem arise in the future where we actually need to use a decades 
old compression algorithm, it can be added later. Furthermore, we should 
probably define a pre-defined dictionary for brotli to use here which is based 
on common strings in certificates, rather than its default one for the general 
web (if such a thing is practical to do here). This could boost efficiency here 
and make it even more worth preferring (also likely reducing the s
 ize of said dictionary, as the default one is 120kB).


Dave


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