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, 07 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 >
- [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Martin Thomson
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Viktor Dukhovni
- Re: [TLS] Certificate compression draft Vlad Krasnov
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Martin Thomson
- Re: [TLS] Certificate compression draft Vlad Krasnov
- Re: [TLS] Certificate compression draft Ryan Sleevi
- Re: [TLS] Certificate compression draft Viktor Dukhovni
- Re: [TLS] Certificate compression draft Martin Thomson
- Re: [TLS] Certificate compression draft Hannes Tschofenig
- Re: [TLS] Certificate compression draft Rob Stradling
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Sankalp Bagaria
- Re: [TLS] Certificate compression draft Ryan Sleevi
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Benjamin Kaduk
- Re: [TLS] Certificate compression draft David Benjamin
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Sankalp Bagaria