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
>>> 
>>> 
>>