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

From: Sean Turner <[email-masked]>
Date: Tue, 6 Jun 2017 09:20:03 +0200

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:
https://mailarchive.ietf.org/arch/msg/tls/U5AmA9OerD_9zTBNWl7ZBC3-HOE

Authors,

Please submit draft-ietf-tls-certificate-compression at your earliest convenience.

All,

I’ve established a GH repo at:
https://github.com/tlswg/certificate-compression
Victor and Alessandro are Admins so they’ll be copying over their repo.

Thanks! 

J&S

---

From: Hanno Böck <[email-masked]>
Date: Tue, 6 Jun 2017 16:23:24 +0200

On Tue, 6 Jun 2017 09:20:03 +0200
Sean Turner <[email-masked]> 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/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Raja ashok <[email-masked]>
Date: Wed, 7 Jun 2017 05:38:59 +0000

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.

Regards,
Ashok

Huawei Technologies
Bangalore, India
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: 06 June 2017 12:50
To: <[email-masked]>
Subject: [TLS] adopted: 

Authors,

All,

Thanks! 

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

---

From: Dave Garrett <[email-masked]>
Date: Wed, 7 Jun 2017 02:23:18 -0400

> 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 size of said dictionary, as the default one is 120kB).

Dave

---

From: Piotr Sikora <[email-masked]>
Date: Wed, 7 Jun 2017 04:03:55 -0700

Hey Dave,

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

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

I compressed them with Brotli (at levels: 1, 6, 9 and 11 - aka Z) and
gzip (at levels: 1, 6 and 9):

facebook.com-ecdsa-chain.pem 4485 (222%)
facebook.com-ecdsa-chain.der 2024 (100%)

facebook.com-ecdsa-chain.br1 1823 (90%)
facebook.com-ecdsa-chain.br6 1673 (83%)
facebook.com-ecdsa-chain.br9 1644 (81%)
facebook.com-ecdsa-chain.brZ 1597 (79%)

facebook.com-ecdsa-chain.gz1 1699 (84%)
facebook.com-ecdsa-chain.gz6 1687 (83%)
facebook.com-ecdsa-chain.gz9 1687 (83%)

google.com-rsa-chain.pem 5749 (266%)
google.com-rsa-chain.der 2160 (100%)

google.com-rsa-chain.br1 1541 (71%)
google.com-rsa-chain.br6 1343 (62%)
google.com-rsa-chain.br9 1348 (62%)
google.com-rsa-chain.brZ 1330 (62%)

google.com-rsa-chain.gz1 1434 (66%)
google.com-rsa-chain.gz6 1398 (65%)
google.com-rsa-chain.gz9 1398 (65%)

Then, I did the same using pre-defined dictionary from QUIC Crypto:

facebook.com-ecdsa-chain.bq1 1823 (90%)
facebook.com-ecdsa-chain.bq6 1505 (74%)
facebook.com-ecdsa-chain.bq9 1482 (73%)
facebook.com-ecdsa-chain.bqZ 1460 (72%)

facebook.com-ecdsa-chain.gq1 1536 (76%)
facebook.com-ecdsa-chain.gq6 1506 (74%)
facebook.com-ecdsa-chain.gq9 1506 (74%)

google.com-rsa-chain.bq1 1541 (71%)
google.com-rsa-chain.bq6 1248 (58%)
google.com-rsa-chain.bq9 1239 (57%)
google.com-rsa-chain.bqZ 1233 (57%)

google.com-rsa-chain.gq1 1317 (61%)
google.com-rsa-chain.gq6 1266 (59%)
google.com-rsa-chain.gq9 1266 (59%)

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?

Best regards,
Piotr Sikora

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Jun 2017 13:36:10 +0000

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] 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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 7 Jun 2017 23:28:48 +0300

On Wed, Jun 07, 2017 at 05:38:59AM +0000, Raja ashok wrote:
> 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. 
> 

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

---

From: David Benjamin <[email-masked]>
Date: Wed, 07 Jun 2017 20:44:43 +0000

> 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

---

From: [email-masked] (Martin Rex)
Date: Wed, 7 Jun 2017 22:50:56 +0200 (CEST)

> 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

---

From: Dave Garrett <[email-masked]>
Date: Wed, 7 Jun 2017 20:43:37 -0400

> (ECDSA) and google.com (RSA).
[...snip...]
> pre-compressed certificates, then maybe Brotli isn't the best and only

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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 Jun 2017 21:18:17 -0700

On Wed, Jun 7, 2017 at 5:43 PM, Dave Garrett <[email-masked]> 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).
> >
> 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.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Piotr Sikora <[email-masked]>
Date: Thu, 8 Jun 2017 16:45:51 -0700

Hi,

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

It's based on certificates, from Chromium's QUIC code:

// kCommonCertSubstrings contains ~1500 bytes of common certificate substrings
// in order to help zlib. This was generated via a fairly dumb algorithm from
// the Alexa Top 5000 set - we could probably do better.

You can see the dictionary here:
https://chromium.googlesource.com/chromium/src/+/19c30774eedcef459c776bde1c06e75bd48bf71e/net/quic/core/crypto/cert_compressor.cc#19

I've opened https://github.com/tlswg/certificate-compression/issues/1
to track this.

> 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 g…

FWIW, Brotli encryption at top compression levels (10 & 11) is quite
expensive, so it probably only makes sense for pre-compressed
certificates and possibly for one-time compression when loading
certificates.

Best regards,
Piotr Sikora

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Jun 2017 09:03:01 +0200

> certificates and possibly for one-time compression when loading

Certificates don't change that often...