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

Alessandro Ghedini <> Sat, 09 December 2017 12:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36CE6128B90 for <>; Sat, 9 Dec 2017 04:30:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MQMsV65g9Smc for <>; Sat, 9 Dec 2017 04:30:27 -0800 (PST)
Received: from ( [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93F94126D0C for <>; Sat, 9 Dec 2017 04:30:27 -0800 (PST)
Received: from localhost (unknown [IPv6:2a02:8010:6241:0:14d2:9c89:db12:b159]) by (Postfix) with ESMTPSA id 398ECDF5B3 for <>; Sat, 9 Dec 2017 12:30:25 +0000 (UTC)
Date: Sat, 9 Dec 2017 12:30:23 +0000
From: Alessandro Ghedini <>
Message-ID: <20171209123023.GA8296@pinky>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1512822625; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; bh=oU2FyUMVj2fRn9HO5jctSFoN9AM9ADI5wxmWJ7BLMjc=; b=RF7K6BdQithcvGlenaTeuGfjoDe5R8WEDxTeI8nWIIsN8nEfV8jqzr6RUctHilvTrVhvjU 0SMBiaZ19MNYtYs2vfofDod4rhMed/HbtL5UEXzpNz3Gpacebk/7MNHeL2VfFmMWAsMNr8 bq79hGxNVMq9FFoGfokeNkvUc8vnIEU=
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Dec 2017 12:30:30 -0000


Sorry for the long delay from the last update.

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