Re: [TLS] Certificate compression draft
Vlad Krasnov <vlad@cloudflare.com> Tue, 07 March 2017 01:37 UTC
Return-Path: <vlad@cloudflare.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 ED7F3129632 for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 17:37:42 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 FBM65MgOiX6A for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 17:37:39 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 A551A12944D for <TLS@ietf.org>; Mon, 6 Mar 2017 17:37:39 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id v190so30791345pfb.1 for <TLS@ietf.org>; Mon, 06 Mar 2017 17:37:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+d0lWXLz8ih0gO4QEwh6Zq+0+7O17RlBRC2yBCEiXd0=; b=oKiPCo6e2KLmTuyvi7sKSEigiB7irSFrSXztN96lixnxwJ42IotW4ttRI2szEjWe4x OFJZn5HW/enRfkvLORhc4f3q6Hss3tzt9Q3x7ofjO+MV2D5xStODW+uOlcCtiOPJYZ8b YbB99qXX2f59pUnpNctAMQAXsTCNYd4EOFA54=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+d0lWXLz8ih0gO4QEwh6Zq+0+7O17RlBRC2yBCEiXd0=; b=kWaOrPfxLvcUUe7iGBnDCe8jBjBPS8ftGch7CL5cid0amzgLxI4fS1NyhzY96o5g1F 0KxMryVemHNByQGu8VeT2AiIPeoubE6aPA+9vFiWjQaWg/shs9BRiobXUp+R1jQV5aco pZ+F1wVk1eP4cMqAkIY6p17BULuZ4s652SgvA9jZS2in2UrBRGBd87RXZ8bh5swJho1o fQaV/VjEyW2POx51sJdVS4IOPGR1fC2+mF2j94XqnGcmbOwJb3KW1FFY7xiqt7u2+m9Y IYpa3NZiwq2EbqCiKQUKnlr9RmiBF89wHeaoqSPz2BFGiremP58gOhQU63ZDgjklT6u5 mZsg==
X-Gm-Message-State: AMke39mxDT8elC9gvF2yyXPDJct18wqWDY4284Mm7lK69nk6F12n8IkGNGXcHgBFZwSycOLG
X-Received: by 10.99.163.110 with SMTP id v46mr23600260pgn.171.1488850658968; Mon, 06 Mar 2017 17:37:38 -0800 (PST)
Received: from ?IPv6:2601:645:8302:ef30:6cbd:8ca2:3194:4aa7? ([2601:645:8302:ef30:6cbd:8ca2:3194:4aa7]) by smtp.gmail.com with ESMTPSA id a5sm11624269pfh.124.2017.03.06.17.37.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 17:37:38 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Vlad Krasnov <vlad@cloudflare.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <CABkgnnWp97aT0zN5WjSQBydFra_kWLsZG0BckS8qeRBXUFpvYw@mail.gmail.com>
Date: Mon, 06 Mar 2017 17:37:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <397C9A5D-BD80-4C58-83DC-02EB66BF0390@cloudflare.com>
References: <CAAZdMacAcSUL4sqLPA1E9-z_VaUSd1P5PpPryO+XQso0eUtThw@mail.gmail.com> <CABkgnnU54SeYDBL=YBRQn0ZThk=C59Rztvr2zkUCLSSv2cKTDg@mail.gmail.com> <CAAZdMaf9n_37soxdJ9ACFFke=iXyux82QEVnr5XgmS2bs2FTYA@mail.gmail.com> <DDF306CD-EFC5-4E24-8ADE-64C432CEEAE4@cloudflare.com> <CAAZdMaeXxA=UC5afPfi-U_zzJYtVVLZtkPvP2hAZmqpqzj5DTw@mail.gmail.com> <CABkgnnWp97aT0zN5WjSQBydFra_kWLsZG0BckS8qeRBXUFpvYw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VeurrltAYmCxWL35nSznZha5e3M>
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: Tue, 07 Mar 2017 01:37:43 -0000
Don't know about neutral dictionary, but simply compressing Cloudflare cert using Google cert, gives an additional 6% using brotli -15. I would rather have a biased dictionary than none at all :) Cheers, Vlad > On Mar 6, 2017, at 4:38 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > > Seems like you might get some traction with adding www. .com, some DN > fields (CN=, O=, C=), common OIDs, with some OIDs attached to values > (like key usage and signature algorithm). Most of that is relatively > short though. > >> On 7 March 2017 at 11:15, Victor Vasiliev <vasilvv@google.com> wrote: >> Hi Vlad, >> >> This is still an open issue: >> https://github.com/ghedo/tls-certificate-compression/issues/2 >> >> The problem here is creating a dictionary that is both neutral with respect >> to >> the certificate's issuing authority, and actually has a noticeable effect. >> So >> far my personal attempts at making such a dictionary have not been very >> successful, but this might change. Even if we get a dictionary, I do not >> expect the effect to be large compared to the effect of just compressing the >> chain in the first place. >> >> -- Victor. >> >>> On Mon, Mar 6, 2017 at 6:32 PM, Vlad Krasnov <vlad@cloudflare.com> wrote: >>> >>> Hi Victor, >>> >>> Have you considered creating a common dictionary, similarly to what SPDY >>> did for header compression? >>> >>> Cheers, >>> Vlad >>> >>> >>> On Mar 6, 2017, at 3:23 PM, Victor Vasiliev <vasilvv@google.com> wrote: >>> >>> Hi Martin, >>> >>> I've measured the effect of compression on a corpus of popular website >>> certificate chains I had lying around (Alexa Top 100k from a few years >>> ago), >>> and the effect seems to be about -30% of size at the median and -48% at >>> 95th >>> percentile (with Brotli, subtract 3-5% for zlib). >>> >>> I think the most dramatic effect from the compression is observed for the >>> certificates with a lot of SNI values, which is not uncommon. >>> >>> -- Victor. >>> >>> On Mon, Mar 6, 2017 at 6:06 PM, Martin Thomson <martin.thomson@gmail.com> >>> wrote: >>>> >>>> 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 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