Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt

From: [email-masked]
Date: Sat, 09 Dec 2017 04:21:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : Transport Layer Security (TLS) Certificate Compression
        Authors         : Alessandro Ghedini
                          Victor Vasiliev
	Filename        : draft-ietf-tls-certificate-compression-01.txt
	Pages           : 7
	Date            : 2017-12-09

Abstract:
   In Transport Layer Security (TLS) handshakes, certificate chains
   often take up the majority of the bytes transmitted.

   This document describes how certificate chains can be compressed to
   reduce the amount of data transmitted and avoid some round trips.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-01
https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alessandro Ghedini <[email-masked]>
Date: Sat, 9 Dec 2017 12:30:23 +0000

Hello,

Sorry for the long delay from the last update.

>    reduce the amount of data transmitted and avoid some round trips.

Here are the changes in this update, based on previous discussions:

* Defined a new CompressedCertificate message instead of re-defining the
  contents of Certificate. Applications can decide to send a compressed
  certificate using this new message, or keep sending the normal uncompressed
  Certificate.
  
  This has a number of small advantages like making it possible for
  applications like WireShark to not have to maintain per-connection state
  when decoding compressed certificates since they could just look at the
  handshake message type instead of having to remember if compression was
  negotiated.
  
  But most importantly, this makes it possible for applications to decide
  whether to compress certificates on a case-by-case basis, even if they
  already negotiated support for it (see next point).

* Added support for client certificates. Both server and client-side support is
  negotiated using the same "compress_certificates" extension, but given the
  previous change, client and server can negotiate compression and only decide
  to receive compressed certificates rather than send them (i.e. a client or
  server is only required to implement decompression).

* Added a compatibility note regarding Certificate-intercepting middleboxes,
  explaining that replacing the Certificate message in TLS < 1.3 might cause
  connections to break.

The only remaining issue is defining compression dictionaries [0]. However,
attempts at defining one that is not biased (as per previous discussion on the
subject [1]) haven't led to anything concrete (i.e. no substantial compression
ratio increase). Both me and Victor don't think this is a blocking issue
though, since dictionaries can be added later on by simply defining new
compression type codepoints.

Also, we think the wire format is pretty stable now, so we are wondering
whether this would be a good time to start the process for early codepoint
assignment (for the extension and handshake message type), so we can start
looking at deploying this.

Cheers

[0] https://github.com/tlswg/certificate-compression/issues/1
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22537.html

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 9 Dec 2017 14:43:37 +0200

>   certificate using this new message, or keep sending the normal uncompressed

The section 3 on extension still seems to be written like Certificate
message was still used.

>   server is only required to implement decompression).

Where is the client certificate compression algorithm signaled?

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Sun, 10 Dec 2017 13:57:54 -0500

> On Dec 9, 2017, at 07:43, Ilari Liusvaara <[email-masked]> wrote:
> 

Are you suggesting a subtle wording change because once “negotiated” compression isn’t always used?  I.e., 

OLD:

   … which is used by the client and the
   server to negotiate the use of compression for their certificate
   chains, as well as the choice of the compression algorithm. ...

NEW:

   .. which is used by the client and the
   server to negotiate the *possible* use of compression for their certificate
   chains, as well as the choice of the compression algorithm. ...

> Where is the client certificate compression algorithm signaled?

Correct me if I’m wrong, but I think the assumption here is that if the client offers both zlib and brotli and the server returns brotli that the client (if it does choose to compress) will use the same algorithm the server chose.

spt

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Dec 2017 09:59:56 +1100

A codepoint might be premature just yet.

The idea of using a new handshake message type is to allow someone to
choose between compressing and not.  But consider the case where both
client and server support non-intersecting sets.  This negotiation
would cause failure, but that would be unnecessary.

You could allow the server to advertise multiple (as the current
format allows), but in that case, when the server certificate arrives
and is compressed, the client can't know which compression method was
used without trialing each.  Similarly, when the client certificate
arrives, the server can't know which compression method was used
either.

I think that the best solution to that problem is to include the
compression scheme in the Certificate message.  It also suggests (to
me at least) that modifying Certificate rather than defining a
CompressedCertificate makes sense, though that might not fit with the
idea that you transform CompressedCertificate into Certificate before
putting it in the transcript.

Or, you could trim the list on the server side to a single value, but
then you have to deal with TLS 1.3 CertificateRequest more explicitly,
which is currently not at all addressed.  In that spirit, I would also
suggest that you describe what happens to a TLS 1.3 Certificate
message that contains extensions (the entire thing is wrapped up as a
whole, I assume).

In light of the changes, this seems like a bug:

   If the server chooses to use the cached_info extension [RFC7924] to
   replace the Certificate message with a hash, it MUST NOT send the
   compress_certificates extension.

The server could send the extension to allow the client to compress
even if it had a cached certificate.

On Sat, Dec 9, 2017 at 11:30 PM, Alessandro Ghedini
<[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Dec 2017 08:09:35 +0200

> would cause failure, but that would be unnecessary.

New handshake message type is pretty much necressary if one wants to
also compress client certificates. Client does not have answer block
outside certificate message, and trying to use that would lead into
chicken and egg problem.

And on supporting algorithms, the main problem is decompressing.
There are very simple trivial "compression" algorithms for both
Zlib and Brotli. And then there are pre-canned responses.

> arrives, the server can't know which compression method was used

Guessing here seems extremely bad idea.

In general, in security protocols, you never want to guess what the
other end intended. Trying to guess meaning is recipe for security
problems.

> putting it in the transcript.

Transforming messages before putting them in transcript? That sounds
like recipe for some very nasty implementation headaches.

AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject
synthetic message, but that is a lot easier than actual message
transformation.

> message that contains extensions (the entire thing is wrapped up as a

Yes, that is what I get from the document.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Dec 2017 08:50:17 -0600

> synthetic message, but that is a lot easier than actual message

My understanding is that this is what is proposed.  FWIW, it's not
that awful for us to implement in NSS.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Dec 2017 17:00:15 +0200

> that awful for us to implement in NSS.

I searched the drafts (both -00 and -01). I find absolutely nothing
to suggest this extension would play any games with the handshake
hash. And considering that extension playing such games is AFAIK
unprecidented, that would warrant rather big warnings.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Dec 2017 09:09:16 -0600

> unprecidented, that would warrant rather big warnings.

Ahh, I read too much into this:

   After decompression, the Certificate message MUST be processed as if
   it were encoded without being compressed.

---

From: Bill Frantz <[email-masked]>
Date: Mon, 11 Dec 2017 12:43:30 -0800

The discussion of this draft makes it sound like implementations 
will have additional complexity to support certificate 
compression. Complexity adds security risks, so just how much 
benefit does certificate compression provide? My naive thinking 
is that most of the data in certificates is signatures, which 
shouldn't be very compressible.

Of course, for small systems, even a small improvement may be important.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 
Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, 
CA 95032

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Dec 2017 17:49:05 -0600

Certificates are pretty wasteful, outside of the keys themselves.
There has to be some significant gains to be had.  I think that we
have discussed generating a dictionary that would be useful for
certificates, so if we do that we won't know the full answer yet (I
see no mention of that in the draft, so I guess that I might be in
dreamland).

On Mon, Dec 11, 2017 at 2:43 PM, Bill Frantz <[email-masked]> wrote:
> The discussion of this draft makes it sound like implementations will have
> additional complexity to support certificate compression. Complexity adds
> security risks, so just how much benefit does certificate compression
> provide? My naive thinking is that most of the data in certificates is
> signatures, which shouldn't be very compressible.
>
> (408)356-8506      | around us, is there any choice | 16345 Englewood Ave
> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032
>
>

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 12 Dec 2017 19:32:16 -0500

> putting it in the transcript.

https://github.com/tlswg/certificate-compression/pull/8

I wrote a PR that splits client and server compression negotiation, and
moves the compression algorithm directly into the CompressedCertificate
message.  The idea is that now you can process this statelessly, i.e.
you don't need greater handshake context to parse a
CompressedCertificate message (helpful for tools like Wireshark and in
general simplifies things).  Also, there is now no "negotiation"  -- one
side just lists the algorithms it support and the other may or may not
send a compressed cert using one of them.

Does this PR address your concerns?

> message that contains extensions (the entire thing is wrapped up as a

Indeed.  This is why the draft compresses the Certificate message, as
opposed to just the certficiates themselves (to cut down the redundancy
in OCSP and SCT messages).

> even if it had a cached certificate.

Yup.  The PR above removes this entire section, since the server no
longer sends the extension to opt into compression.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 12 Dec 2017 19:40:59 -0500

> see no mention of that in the draft, so I guess that I might be in

Indeed.  I've presented some numbers on this back in Chicago:

https://datatracker.ietf.org/meeting/98/materials/slides-98-tls-certificare-compression/

There is currently no pre-shared dictionary in the draft, since deciding
what to put into that dictionary is somewhat of a hard question (both
from the technical and from the ecosystem perspective).  I'm still
working on making one, but the current plan is to not block the draft on
this, since the simple scheme is already quite effective, and adding it
is a matter of adding another compression algorithm to the list.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Dec 2017 18:43:19 -0600

> https://github.com/tlswg/certificate-compression/pull/8

That's a lot cleaner.  Thanks.  Some minor quibbles, but I like this
construction far better.

A question about client certificates prior to TLS 1.3: Are we happy
making compression for client certificates only available in TLS 1.3
(or higher if we can assume that we will maintain parity in future)?
I think that I can live with that.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 12 Dec 2017 20:04:26 -0500

> I think that I can live with that.

Pretty much.  The initial draft did not have support for client
certificates, and besides, due to middlebox issues, I expect everyone to
deploy this only for TLS 1.3+ anyways.

---

From: Sean Turner <[email-masked]>
Date: Wed, 13 Dec 2017 12:30:09 -0500

What should happen when my silly implementation sends both the Certificate and CompressedCertificate messages?

spt

> On Dec 9, 2017, at 07:21, [email-masked] wrote:
> 
>

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 13 Dec 2017 13:58:09 -0500

You mean sending both of those messages in series?  This would be
equivalent to sending a second Certificate message, so whatever TLS says
should happen in that case (I assume it's unexpected_message alert).

---

From: Sean Turner <[email-masked]>
Date: Wed, 13 Dec 2017 15:04:46 -0500

Exactly, but since are different messages I think the draft needs to say that.  And, to be on the safe side the draft should if you send one don’t send the other.

spt

> On Dec 13, 2017, at 13:58, Victor Vasiliev <[email-masked]> wrote:
>

---

From: Hanno Böck <[email-masked]>
Date: Wed, 13 Dec 2017 23:39:10 +0100

Hi,

The deployment of TLS 1.3 was delayed because Internet middleboxes
broke when they saw unknown TLS data.

I guess it's plausible to assume that the same problem will show up
with compressed certificates. Has any thought been given to that?

-- 
Hanno Böck
https://hboeck.de/

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

---

From: David Benjamin <[email-masked]>
Date: Wed, 13 Dec 2017 22:44:19 +0000

> with compressed certificates. Has any thought been given to that?

Everything after the ServerHello in TLS 1.3 is encrypted. A non-terminating
middlebox cannot mess with it, and a correctly-implemented terminating
middlebox would just not negotiate the extension.

As for TLS 1.2, I do not think this specification has any hope of being
deployable in TLS 1.2. We would only negotiate it in TLS 1.3 for BoringSSL.
This isn't much of a loss as this requires a code change to deploy anyway,
and the code change may as well carry TLS 1.3 too.

(To that end, it may be better to explicitly say in the document that the
extension applies to TLS 1.3 only, so other folks don't try to deploy it at
TLS 1.2 and have things break in buggy non-compliant networks they aren't
testing in.)

David

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 13 Dec 2017 18:01:24 -0500

> TLS 1.2 and have things break in buggy non-compliant networks they aren't

We do discuss the middlebox problem in the document, but we leave it up to
the implementers to decide what to do with it.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Dec 2017 23:46:50 +0200

> That's a lot cleaner.  Thanks.  Some minor quibbles, but I like this

Yeah, same here, I like this construction far better than the -01 one.

> I think that I can live with that.

As others have said, this extension is basically undeployable with
TLS 1.2 because middleboxes.

Also, assuming parity in the future might not be a good idea. Does
anyone have any idea what TLS 1.4 might be about[1] (TLS 2.0 would
likely be about cleaning representation, but that would likely be a
bad idea)?

[1] Not Post-Quantum Cryptography. Integrating PQC into TLS 1.3 is not
a difficult task (once you know the trick). And I do not see TLS
changes making it any easier without weakening security.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Thu, 14 Dec 2017 22:43:34 +0000

> TLS 1.2 because middleboxes.

Another observation about the middlebox issue: if we leave the text as-is,
where it is defined for TLS 1.2 server certificates, but we all silently
agree that servers should decline it at TLS 1.2, clients are still
obligated to implement it in their TLS 1.2 state machine because the
advertisement is the same.

If we're never going to deploy it in TLS 1.2 anyway, this seems like a
waste of the complexity budget. Better to say it is not defined for TLS 1.2
at all because of non-compliant middleboxes and avoid all this ambiguity.

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 27 Dec 2017 15:43:41 -0500

> at all because of non-compliant middleboxes and avoid all this ambiguity.

This is a good point.  I've written a PR to change the extension to
1.3-only: https://github.com/tlswg/certificate-compression/pull/9