Re: [TLS] Certificate compression draft

David Benjamin <> Wed, 05 April 2017 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 202E012948B for <>; Wed, 5 Apr 2017 10:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pPfYpYfnl6H7 for <>; Wed, 5 Apr 2017 10:16:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48DFF129480 for <>; Wed, 5 Apr 2017 10:16:03 -0700 (PDT)
Received: by with SMTP id g2so11003455pge.3 for <>; Wed, 05 Apr 2017 10:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YavPCGsqN371NeP53bHJTEgLNJPXzHuasfV6EnjGx04=; b=DwiIzmcyEDd4KdGc4unm89Y4S3VoErf3NqNI+FvKb2op6i9nqKi3pMbGUolbw48lRb qInOREbzqRDvV31lq0wRu6yTAJNRXFC9HYXa58zEBVxNrJuqfEH4F+A/BDVwCCx1e1y9 Xx3hyYziTpg+h739adrqYEVphJQq4YdHVLWhU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YavPCGsqN371NeP53bHJTEgLNJPXzHuasfV6EnjGx04=; b=GLDSt7rUzMSyVxK+i7l/ddfczvOY1IHORW4cxKtUMJpC+ko6QTbTbfkE4tkhGAkTok QpGQQabX5QagllRZbPRKzIQOcNiZTL4SPCED60dEpV+tHa4XC4fplhne+SigoOX77Cr/ 5ZGEGCYgyrQuHDgxNQBi17c6xacgBrPADSfRPqrxC4ieQnkHVsV/l6McPDVTvg6yuKrn Pk7w67Qi3Hc+ykEZ1J8xcUs567yN/FZfxK2a8nRRZ/hmrDjfrZ7EqQKpHkeHjDzfNIMQ oEP+NGNfLdu6/QIBChr5pEPiNbQF0hOLYU8uwm2lqY5ELz5PVMgtQWCaZcDhgMc5DVR0 TDuQ==
X-Gm-Message-State: AFeK/H1Lv/83Ftoo3sTFrVhywx0FwflPw+NrDJ4rFRe5aMrOVVYYf4Kuo5DQgxlbAF+FS3PosbLoGxqAYjAwwVqF
X-Received: by with SMTP id f1mr37584921pld.77.1491412562818; Wed, 05 Apr 2017 10:16:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 05 Apr 2017 17:15:50 +0000
Message-ID: <>
To: Benjamin Kaduk <>, Eric Rescorla <>, Ryan Sleevi <>
Cc: R Balaji <>, Sankalp Bagaria <>, "Bagaria, Sankalp" <>, "" <>
Content-Type: multipart/alternative; boundary=94eb2c18a36e058a08054c6e8c80
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: Wed, 05 Apr 2017 17:16:05 -0000

On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk <> wrote:

> On 04/05/2017 09:21 AM, Eric Rescorla wrote:
> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <>
> wrote:
> Does cached-info not represent a privacy info-leak by disclosing past
> sessions prior to authenticating the new session? Versus compression, which
> limits it to the session and thus reveals no new/additional information.
> That was certainly true for TLS1.2
> This will also be true in TLS 1.3, even with encrypted certificates
> because (hopefully) they
> will be a lot smaller. Though you could of course pad out to the same size
> :)
> The elephant in the room being that an attacker watching the network can
> replay the observed ClientHello but using its own KeyShare and read the
> resulting encrypted certificate reply.  (h/t davidben)

(Supposing that the server is a traditional server that accepts multiple
requests and does not select the certificate based on external factors in
the transport or elsewhere, which means you're selecting by things not
covered by TLS's transcript.)

Also, while one could compressed pad up to uncompressed length and make
compression useless, hiding whether your certificate was compressed is not
a plausible goal. More plausible is hiding which certificate was selected.

Without compression, your certificates still have different lengths, so you
would need to pad up to max(certificate_message(cert) for cert in certs)
anyway, where certs is all identities your particular server wishes to make
indistinguishable. Maybe chunk up to a boundary beyond that if you want.

With compression, you pad up to max(compress(certificate_message(cert) for
cert in certs). Maybe chunk up to a boundary beyond that if you want.
(Packet boundary for the QUIC use case?) This means you're now bound by
your worst cert rather than your selected cert, but one could still expect
a size win.

This is, of course, all assuming your server setup is somehow such that the
above pachyderm doesn't apply.