Re: [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07

Alessandro Ghedini <> Thu, 05 December 2019 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0508120870; Thu, 5 Dec 2019 08:42:22 -0800 (PST)
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, SPF_HELO_NONE=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 TH9x63BEUnpP; Thu, 5 Dec 2019 08:42:20 -0800 (PST)
Received: from ( [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A625120865; Thu, 5 Dec 2019 08:42:18 -0800 (PST)
Received: from localhost (unknown [IPv6:2a02:8010:6241:1:dd55:accf:56f0:dc88]) by (Postfix) with ESMTPSA id 0840ADF287; Thu, 5 Dec 2019 16:42:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1575564136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KpZLPiYmt/m1coi0nQXt8YhbFG98w2KwkdUUeDqNK3U=; b=VSgq/asPqJ9njj3XNg/B9C9LAeSzxbNoCQomPrLPsi8SQYyaREnaStD9KU5gGYpOBuKulQ r9wYCW58IIi+jEfuV7bYY+DTz6hhgtSIU/17XI5EQ7Ulf0Gf9JERcH/Xq+jf7ImRFBbNiN 0nNBf1ji7/v8yUlcomy65iutVWAAp/k=
Date: Thu, 05 Dec 2019 16:42:12 +0000
From: Alessandro Ghedini <>
To: Christian Huitema <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <>
Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07
X-Mailman-Version: 2.1.29
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: Thu, 05 Dec 2019 16:42:23 -0000

On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker wrote:
> Reviewer: Christian Huitema
> Review result: Has Issues
> I have reviewed draft-ietf-tls-certificate-compression-07 as part of the
> security directorate's ongoing effort to review all IETF documents being
> processed by the IESG. These comments were written primarily for the benefit of
> the security area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.

Thank you for the review!

> Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to
> negotiate and then apply compression of the Certificate message. The draft is
> clear and well written, and the extensions are already widely deployed. I would
> like to say "ready", but I have to say "almost".
> This document is almost ready, except for one nit and one issue.
> First, one nit. The draft references the "Certificate message", but there is no
> formal reference section 4.4.2 of RFC8446. Please add that, maybe at the
> beginning of section 4. It may seem obvious to members of the TLS WG, but
> uninformed readers will appreciate.

Makes sense. I created
to address this.

> Second, my actual concern. Compression may leak information, because different
> certificate chains will compress differently. The authors mention that an
> attacker will not be able to inject data in the certificate chain, and thus
> that attacks of the CRIME variety are unlikely. That's correct, but that's not
> the entire story.
> TLS 1.3 will encrypt the compressed certificate message but the length of that
> message could be deduced from the length of the server's encrypted message.
> Attackers might be able to derive from that length the identity of the server,
> even if the SNI is encrypted.
> One could say that in the absence of compression the length of the certificate
> chain is also available. Indeed, the problem is flagged in
> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server)
> SHOULD pad the Certificate message, via padding at the record layer, such that
> its length equals the size of the largest possible Certificate (message)
> covered by the same ESNI key."
> Certificate compression introduces a level of complexity here. If only some
> servers in the anonymity set support compression, attackers can work with a
> smaller anonymity subset. If all attackers support compression, the padding
> should try to match the largest Compressed Certificate.
> It might be good to discuss this issue in the security consideration section.

I agree tha this is worth discussing, but it seems like it belongs in the ESNI
draft itself, so implementers of ESNI will be more likely to take compression
into consideration. That is, we can expand the section you quoted to also
explicitly mention certificate compression. What do you think? I can look into
proposing a PR for this.