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

Martin Thomson <> Sun, 10 December 2017 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B53CC126D3F for <>; Sun, 10 Dec 2017 14:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XIh9DW7yB_u9 for <>; Sun, 10 Dec 2017 14:59:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B284D1242EA for <>; Sun, 10 Dec 2017 14:59:57 -0800 (PST)
Received: by with SMTP id 184so10485440oii.2 for <>; Sun, 10 Dec 2017 14:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k1RgN2DdRW4nmawXphVIjYpS2yRPNIjN4IJWhbrPOSQ=; b=QtuMkmJor1YWxk702/oRHAXkt0IKQ0jFZ9iWJ/R619WQCyvVyI3Q2gQeXIXm52z8rE koCUEwLRcmpNP68+pAXcebxWTD2l2qjjNZKOpU0GxD/KQUwuEjmQZo+uwELPMos/nPZv 4M36Kq8jAp2/z1eRfvPuWS2a7gw0UwnX2BJbfaGieJNEWmcng4NVFviDGr0GQsWkIOak TU7RMAb4wENYLfZjquy/e1PgQdo5mD02DgjcnhNpxNTguGFkOvQgek4rrTfAMDGuDTMU FAUXn2cP7Zxh6Eu4S+P9RIAYjzWDVkdE78FvOu9HtJ9szTz/0mqYd1pr7KyTU9Dx+Of8 Ycbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=k1RgN2DdRW4nmawXphVIjYpS2yRPNIjN4IJWhbrPOSQ=; b=YUmmvNa4rIsOdN+7FJe/Vmg9+xv/X3zsBer/PxqkabAe3MyEuKJB00x+rpBe1edIew /mIUDy1V2PrXJskQK/5oj4VGql51YjYW8jSY6Gg3ULw/A/FlSyAiBfyVuPuVCDJYGVJY hHE2FRStYb0Q3wrPSSz7RdjFhqGadx1FaaBp9E8y44q9/vB/jhEpQO5HDK3cC4TVyku7 vD5EtNgN/9ZSESw1PyjlbrfZse8On+1T6w0R3H/9sybXi+MBBRjNOTDmSdbr5CzJ6l7h KnF4TFvH9tH1wsyiODruZOnnQoUKIvew1fo7DRL4aEubawMG9TqGIcZT5esSnKGHYhAQ 5afg==
X-Gm-Message-State: AJaThX4E575iaJXq7Y7rDONd1rll0iycoyyHWcV0WibafyUIbRQ4xpPb ZM/hKLSFiEI+Hrgx98wVeInigNh7NLxqTKNQtsSRGE3G
X-Google-Smtp-Source: AGs4zMYMq5NMLHrGPn66rP4QGPukjkQmXIT/pERTro7cTBGt4MSXlAUsiw1uA76VC94uNQbkf+jQXS2UjF1NPOv1qGc=
X-Received: by with SMTP id 65mr30483458oik.84.1512946796706; Sun, 10 Dec 2017 14:59:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 10 Dec 2017 14:59:56 -0800 (PST)
In-Reply-To: <20171209123023.GA8296@pinky>
References: <> <20171209123023.GA8296@pinky>
From: Martin Thomson <>
Date: Mon, 11 Dec 2017 09:59:56 +1100
Message-ID: <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
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: Sun, 10 Dec 2017 22:59:59 -0000

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

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
<> wrote:
> Hello,
> 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
>   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]
> [1]
> _______________________________________________
> TLS mailing list