Subject: [Last-Call] Secdir last call review of draft-ietf-tls-certificate-compression-07

From: Christian Huitema via Datatracker <[email-masked]>
Date: Thu, 28 Nov 2019 17:01:37 -0800

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.

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.

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.