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

From: [email-masked]
Date: Fri, 26 Jan 2018 02:18:21 -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-02.txt
	Pages           : 7
	Date            : 2018-01-26

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-02
https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-02

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

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: Fri, 26 Jan 2018 10:26:59 +0000

Hello,

Here's a fresh new update based on the latest round of discussion.

> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-02

The main changes are:

* The CompressedCertificate message itself now carries the selected compression
  algorithm, rather than it being specified in a ServerHello extension. This
  means that client and server can independently select an algorithm for their
  own certificates (or none at all as in the previous version) rather than
  using the one picked by the server.

* The server now advertises support for compressed client certitificates as an
  extension in the CertificateRequest message (so different sets of algorithms
  can be used for client compression).

* The feature is now TLS >= 1.3 only, due to the dependency on extensions in
  CertificateRequest and to avoid middlebox interference.

Me and Victor would like to ask for early codepoints assignment again, if you
think we are ready now.

Cheers

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Jan 2018 09:22:40 -0600

> Here's a fresh new update based on the latest round of discussion.

Thanks, the changes look good.

The new note about "no ServerHello extension to echo back" makes me
wonder if (not) echoing back in Certificate should also be mentioned,
since the TLS 1.3 paradigm is that CertificateRequest extensions are
also "requests" that can get "responses" in the Certificate message.

I also wondered whether there was any sense in reserving codepoint 0 (of
CertificateCompressionAlgorithm) for "uncompressed".  I guess not, since
support for uncompressed certificates is implicit by means of not using
the extension.  But sometimes keeping value 0 (basically) reserved is
still useful.

-Ben

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 30 Jan 2018 17:02:31 -0500

> also "requests" that can get "responses" in the Certificate message.

True, though I guess this depends on your definition of "response"?

> the extension.  But sometimes keeping value 0 (basically) reserved is

I've considered that, but decided that this would just introduce two ways
to do
the same thing (send certificate uncompressed), so I decided against it.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Jan 2018 15:41:34 -0600

On 01/30/2018 04:02 PM, Victor Vasiliev wrote:
> On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>

I'm thinking of the text in section 4.2:

   Extensions are generally structured in a request/response fashion,
   though some extensions are just indications with no corresponding
   response.  The client sends its extension requests in the ClientHello
   message and the server sends its extension responses in the
   ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate
   messages.  The server sends extension requests in the
   CertificateRequest message which a client MAY respond to with a
   Certificate message.  The server MAY also send unsolicited extensions
   in the NewSessionTicket, though the client does not respond directly
   to these.

   Implementations MUST NOT send extension responses if the remote
   endpoint did not send the corresponding extension requests, with the
   exception of the "cookie" extension in HelloRetryRequest.  Upon
   receiving such an extension, an endpoint MUST abort the handshake
   with an "unsupported_extension" alert.

-Ben

> I've considered that, but decided that this would just introduce two
> ways to do

Sure.  I don't see a reason to add a code point for uncompressed, but
maybe there is an aesthetic argument for leaving 0 reserved entirely. 
But I definitely do not insist on anything.