Re: [TLS] Certificate compression draft

Hannes Tschofenig <> Tue, 07 March 2017 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEC56128DF6 for <>; Tue, 7 Mar 2017 00:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xlA96FPojS1x for <>; Tue, 7 Mar 2017 00:15:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07715127A90 for <>; Tue, 7 Mar 2017 00:15:01 -0800 (PST)
Received: from [] ([]) by (mrgmx103 []) with ESMTPSA (Nemesis) id 0M8MyE-1cOhOn0jwI-00vyB6; Tue, 07 Mar 2017 09:14:55 +0100
To: Victor Vasiliev <>, "" <>
References: <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <>
Date: Tue, 7 Mar 2017 09:14:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EOmTfn2rCXl4g4OullFUjxvx9mdgBUKbn"
X-Provags-ID: V03:K0:YiueBd+2cIoesNRgnx55bRTAu8hc2hBrFbqqzgyQC2mmN5GlVbY ogTm80c3H6h7lish75j48KqIuQ/l3cqUPNWlQQKLZLVNxw0xa74IDmJvEMlMVAw3lErvDeX J4orqIWX4e8YayUQfZErQazn5ed+GF2c/JsBm0eB6e9UZZc6IxLSsFCZ2J+zNFjPS9WtWX8 donY3qyVvgp4qGCOOALwA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:YYqI38y/E9A=:1IoLYBF0AA4kXCaqSlr0RZ r4FG9gVyQD1pL9VauA9SwGlDqtBpedFooplhSl3R/iVPE0ZKAUMEdR+k5WDATQHXhKe+wtX8o thA4LBkGGJJ9JrwsWH4pf+7GEG7PNh5CQlSFy48DrZV4/L5gQCPOtq6wuAKxZN0o8CVzVDq+A TuodJY4mIASxzlCDxrlRiYjzdGHNKJfLl2LQAzRGMBbPXFEY8+JwhoqcfoYNj69ah0CiSTbT5 hoCsSwwd64Kyrv6/jgWoyNABmV7NaQ7DJvz1TH4Rt0Pb9TV10XOs0e0IFhvDjbgBQFjSZH6aB TL8gQkyWU250C2FYXwChWXht1gVyAKwb18IXDcziv5BHHEnip+khSfkyDavdT90v36/MNfd/n tfiG9pJ7ecMGcSSGsWES5avJa8Gte6K+3/Pkw0YvfH1XTBxr54dfGYAcek7/69G3D1EECW/ml J+yzY0Pj1o64HEqXZCpu84UfmU//kENcyZq/fGO2Lv7d74a/02D8AJztTX4IljgeLVt2T+g1U ZMOr04G3Io5q22Hz19q/9yRB1Ud99EM8HLqcyYSTP4OCQ62vFSSCpU+58p+U5b5sY+QAUlkco ipTuvi0DszmPx6Qx78DD5cdBadv9cu1ghOQBn0ckTl8JXJntKj+OA/MyhBatEb2CSoDQFUMTS MUA+5YTgyEOBQo6ssSv4QUkoxPB1tYk5gb3G5LpM/0ACNj/NwWgtOlgOLTgwIMLkyoO5N2Xsk oFZQi3U3Sgh7yur0ItStm9bJU/Z9nIfPebT21xQ3r0EYX/zHltpimy7dNIdlctPsZ9DyoqV7g f5+h96awj7F1gU3p3yVqQwB+LpGT2LlkNt/4daUNekLzVdRVH3BzEQs1ZoLqUZQrOkJTEACqQ m/n5GsXmTUwyaljmGz+LVkfyc51eeja6nu+f3no9at2VZ2fIXhhq9XZGdMa8U8f+r8rz+Xmew yZwbRRM+rpwCA6J9XqWzLiO50v4tu56Hkn33sjNexsiLByHxeYx7EUl73B1lWERPD6ctqBa9v 8g==
Archived-At: <>
Subject: Re: [TLS] Certificate compression draft
X-Mailman-Version: 2.1.17
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: Tue, 07 Mar 2017 08:15:04 -0000

Hi Victor

why don't you use RFC 7924:

This provides an even better "compression" ratio.


On 03/06/2017 11:58 PM, Victor Vasiliev wrote:
> Certificate compression has been discussed on this list briefly before, and
> there was some interest in at least considering a draft for it.  The
> draft now
> exists (co-authored by Alessandro and myself), and it can be found at:
>   [ GitHub repo: ]
> The proposed scheme allows a client and a server to negotiate a compression
> algorithm for the server certificate message.  The scheme is purely
> opt-in on
> both sides.  The current version of the draft defines zlib and Brotli
> compression, both of which are well-specified formats with an existing
> deployment experience.
> There are multiple motivations to compress certificates.  The first one
> is that
> the smaller they are, the faster they arrive (both due to the transfer
> time and
> a decreased chance of packet loss).
> The second, and more interesting one, is that having small certificates is
> important for QUIC in order to achieve 1-RTT handshakes while limiting the
> opportunities for amplification attacks.  Currently, TLS 1.3 over TCP
> without
> client auth looks like this:
>   Round trip 1: client sends SYN, server sends SYN ACK
>     Here, the server provides its own random value which client will
>     have to echo in the future.
>   Round trip 2: client sends ACK, ClientHello, server sends
> ServerHello...Finished
>     Here, ACK confirms to server that the client can receive packets and
> is not
>     just spoofing its source address.  Server can send the entire
> ServerHello to
>     Finished flight.
> In QUIC, we are trying to merge those two rounds into one.  The problem,
> however, is that the ClientHello is one packet, and
> ServerHello...Finished can
> span multiple packets, meaning that this could be used as an amplification
> attack vector since the client's address is not yet authenticated at
> this point.
> In order to address this, the server has to limit the number of packets
> it sends
> during the first flight (i.e. ServerHello...Finished flight).  Since
> certificates make up the majority of data in that flight, making them
> smaller
> can push them under the limit and save a round-trip.
> Cheers,
>   Victor.
> _______________________________________________
> TLS mailing list