Re: [TLS] Certificate compression draft
Martin Thomson <martin.thomson@gmail.com> Mon, 06 March 2017 23:06 UTC
Return-Path: <martin.thomson@gmail.com>
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 0E92D12896F for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 15:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6W7AySfDSvlu for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 15:06:45 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 963F6129810 for <TLS@ietf.org>; Mon, 6 Mar 2017 15:06:45 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id v125so118108807qkh.2 for <TLS@ietf.org>; Mon, 06 Mar 2017 15:06:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WyErdY0HlEGrVDWSZl6hVRh1/jVdzG3JzOR5QZWN4As=; b=h+2UfAq2jPfs0BkayAlBzcD7rq1Hvf3j1MFvAff+xrx/9pGAwudn8F3IWWCFtjw1ek yEtATpZLZwIDDYulElr/jAJ4u5N7n2KUNE2iSLUTAwh5fvX5DEogUHMAyyjOzgE6uX3x lb5wfPuIF4STABgDBDaOyBmlddkljOK2YQYQQID2sqPmpw+EoggjrkPYgqGegkJ3+9/e YKBF+s7IoZmuKB5RGd8JBTGziIcDwBAgPDhIqMT1OkSDLhhtt0V7E4pnhe9kc3hEXllK E1rMAp+fInM0ds32j0m2GfCzMcSxlbI2B2BnZvVvjGNio6aTapAjjW8NBK9NkpVHnZs6 bP7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WyErdY0HlEGrVDWSZl6hVRh1/jVdzG3JzOR5QZWN4As=; b=goPA0YeMAf2/9r4eHwrvI3HzSDk55mnxFq+o4pwCnjHWQGnhNw0CdXjP6P0rHW/pQW 00km8/qjYnr6oG6iscuwiZVkEbdHiJVJBmddIVVkMNZPlBeIg8uzjet53h2LlaTK1q1B Dlg5TmRk0sEoxbwnAfzifw5WV+4nJ85O2TXb7mgdN8A6IS00m/NEDTowwq/uuMVcEUFE pJEJY6M2lQcE3zwwaZF/w8spXUdN9tAXPSIoHTypnTTJL3oMmdb6Tow7eIS+EHNmi9CR rVHFf/a0oaRbW0NhoG7N7mOOXmwkSvqlveqG/DwS3ePNouNsiXEhoyVlL1ypBjD0EzfQ bsPg==
X-Gm-Message-State: AMke39lgH08LIw60Z6pAn1psscuysy/uIDkaM2GqsHZI9YESKwtMALlpvW0TmXwArad9HON1kPb+CZkMLXJx3Q==
X-Received: by 10.55.151.7 with SMTP id z7mr18326260qkd.316.1488841604765; Mon, 06 Mar 2017 15:06:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 15:06:44 -0800 (PST)
In-Reply-To: <CAAZdMacAcSUL4sqLPA1E9-z_VaUSd1P5PpPryO+XQso0eUtThw@mail.gmail.com>
References: <CAAZdMacAcSUL4sqLPA1E9-z_VaUSd1P5PpPryO+XQso0eUtThw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 07 Mar 2017 10:06:44 +1100
Message-ID: <CABkgnnU54SeYDBL=YBRQn0ZThk=C59Rztvr2zkUCLSSv2cKTDg@mail.gmail.com>
To: Victor Vasiliev <vasilvv@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DTSUVBFdriW1TGZUNi1op29EZ5o>
Cc: "tls@ietf.org" <TLS@ietf.org>
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: Mon, 06 Mar 2017 23:06:47 -0000
Hi Victor, Do you have any evidence to suggest that this reduces size in any meaningful way? Certificates tend to include both repetitious values (OIDs), and non-repetitious values (keys). On 7 March 2017 at 09:58, Victor Vasiliev <vasilvv@google.com> 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