Re: [TLS] Certificate compression draft

Eric Rescorla <> Tue, 21 March 2017 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66A38129410 for <>; Tue, 21 Mar 2017 16:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y4leTDhrNXiM for <>; Tue, 21 Mar 2017 16:31:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CEA5129409 for <>; Tue, 21 Mar 2017 16:31:32 -0700 (PDT)
Received: by with SMTP id v76so119792555ywg.0 for <>; Tue, 21 Mar 2017 16:31:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=koHanlToUUIPHRT0yxWbkVNMy9GBLs6rDFWDARN7N8o=; b=sOJkgHAR83xF7wah+Ej1pKHAmCHp9g+QXj3dbtAumQE8u7j/EcsC0LpovwJCtLVXhA GpgrC1QRmuiCkdEbuWCXjQte4+iBovesiMoOu4Ol70HpHnMxbJiP0Zr06EC1R9KoQAMl E3LQKMKWldgJrX2ttsvCWparP/eVePe92JKaMK319YAuUa0VTqjaLOW4nwiqCYSUkv27 yt1+lAXEruKcPOeBpL8s/jjUTnNESnvCylpU4OCJbxgCek9clkYeVoEq6uFLdMkrpyoo 3N59mcbEY1VTrfA9iLp5eK1P78w3p/aQeaof4a8D1h0m2Ii/iPOeX2+IdSaMQQ19dXCE ovLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=koHanlToUUIPHRT0yxWbkVNMy9GBLs6rDFWDARN7N8o=; b=DLCZq62ZJ9fysQFPniT4nxig+S6pCF+xaQGBhJGFoUIlj0DrcrygpkV8L9sHF4lKBC AVYrV5Zvl+F4qrKPgd6V6sSpnHtIWRf8buuFtJ9b1aLlw9SLgSto8GRm8fxZiC22HKRJ 2p9+zKProVtkjHCBcpA+KExGopbZqQlxGvoZVW6EjPXCoBP4Frjl+QoJyCzsNI/SkqKc OCobq9oQoHWqlVtJgK9vQOwFX3WBjkjfUHsb/ynBZAKPYMUecKemNGvq6FZXyOGRP43q 4RaRR8P0NmeTO+lfqXIe6oI6hx6/g8GDheih1Qc7DW4nh8MIzo0kQW9zQ1BxVe3zkedJ bPpQ==
X-Gm-Message-State: AFeK/H3r5gdeI1h5w7r/f/ZLx4PNRuLC5CD05sWzwP/+mqx0GYqxE0pnYGzknsgXfHdobk/oMmF/DDoffgIoJA==
X-Received: by with SMTP id y5mr20687657ywc.120.1490139091519; Tue, 21 Mar 2017 16:31:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Mar 2017 16:30:50 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Tue, 21 Mar 2017 16:30:50 -0700
Message-ID: <>
To: Victor Vasiliev <>
Cc: "" <>
Content-Type: multipart/alternative; boundary=001a11493644375fec054b460bdb
Archived-At: <>
Subject: Re: [TLS] Certificate compression draft
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Mar 2017 23:31:34 -0000

This proposal seems like a reasonable idea. One question I had is what the
point of the "uncompressed length" field is:

       struct {
            uint24 uncompressed_length;
            opaque compressed_certificate_message<1..2^24-1>;
       } Certificate;

I initially thought maybe it was a sanity check, but if so it's not a very
one. I see that in S 5 you encourage receivers to limit the compressed
length, but having it expressed like this doesn't seem like that useful a
security measure because the attacker gets to choose both the compressed
data and the length. Is the idea just to let the receiver pre-allocate a
for decompression?

The text says:

   compressed_certificate_message  The compressed body of the
      Certificate message, in the same format as the server would
      normally express it.  The compression algorithm defines how the
      bytes in the compressed_certificate_message are converted into the
      Certificate message.

I assume in this case "body" means "not including the header bytes"? I
guess it's
redundant, but it might be worthwhile being very precise


   The implementations MUST limit the size of the resulting decompressed
   chain to the specified uncompressed length, and they MUST abort the
   connection if the size exceeds that limit.  Implementations MAY
   impose a lower limit on the chain size in addition to the 16777216
   byte limit imposed by TLS framing, in which case they MUST apply the
   same limit to the uncompressed chain before starting to decompress

Do you mean "upper" rather than "lower" for limit?


On Mon, Mar 6, 2017 at 2: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:
> certificate-compression/
>   [ GitHub repo: ]
> 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