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

[Alessandro Ghedini <[e-mail]>]

Hello,

Sorry for the long delay from the last update.

On Sat, Dec 09, 2017 at 04:21:39AM -0800, [e-mail] wrote:
> 
> 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.

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