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
>