Re: [TLS] Certificate compression draft

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 07 March 2017 08:15 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC56128DF6 for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 00:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlA96FPojS1x for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 00:15:02 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07715127A90 for <TLS@ietf.org>; Tue, 7 Mar 2017 00:15:01 -0800 (PST)
Received: from [192.168.91.177] ([80.92.114.23]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8MyE-1cOhOn0jwI-00vyB6; Tue, 07 Mar 2017 09:14:55 +0100
To: Victor Vasiliev <vasilvv@google.com>, "tls@ietf.org" <TLS@ietf.org>
References: <CAAZdMacAcSUL4sqLPA1E9-z_VaUSd1P5PpPryO+XQso0eUtThw@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <1cf1ff2e-3784-eac0-461f-335c043a8917@gmx.net>
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: <CAAZdMacAcSUL4sqLPA1E9-z_VaUSd1P5PpPryO+XQso0eUtThw@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/tls/aNZTAQ-De1tFZtJDcFmO5i5ya7w>
Subject: Re: [TLS] Certificate compression draft
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 08:15:04 -0000

Hi Victor

why don't you use RFC 7924:
https://tools.ietf.org/html/rfc7924

This provides an even better "compression" ratio.

Ciao
Hannes


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:
> 
> https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/
>   [ GitHub repo: https://github.com/ghedo/tls-certificate-compression ]
> 
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>