Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt

Victor Vasiliev <> Wed, 13 December 2017 00:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F825127601 for <>; Tue, 12 Dec 2017 16:32:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 bYAlie-opzbb for <>; Tue, 12 Dec 2017 16:32:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2161C12711D for <>; Tue, 12 Dec 2017 16:32:18 -0800 (PST)
Received: by with SMTP id k19so1749806qtj.6 for <>; Tue, 12 Dec 2017 16:32:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t5f5XugpjK2ZRZ5Oxq7wlG5TGpXy+6FoGvqc0hBjnhY=; b=p6jkcb7Kh4DZnAshZ/b7guTNS3/egvD9CCsH0qe9j6PLyzL1xCY8fU4/JjIFf/nWH3 6NTSMno/i5JlwpojRb8uLU4toxTf7lyFvbAh6CmS8NpLWfjDkheTd6nfD8bQD6Sn/TZu rbizgB3CZJPn292mWHHXmw8VuBzGfLyNIQcRVy937bygbx9/e/Q5OdXS2XqaWSAaQVYL isPLPLPMsRlhd1GOtO0YbleW7LVE/+p0cV1GcHZ/QirHgSxuqp3soPVT8okAOD5jnvSf SST8RlefhxcAbGOUq6G89ci78eLLRH3Te6ihFQMKMKl9ExbVtJj8AT6WdLU0SW4AqUtv I60Q==
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=t5f5XugpjK2ZRZ5Oxq7wlG5TGpXy+6FoGvqc0hBjnhY=; b=rI6L2xg2THEfzIb9/2bhpfrT2DRXOAeuVF8nh9v4ELiv+fDZX1WUZVBTv4rv6VS1au Zf2rXcgGX4H9N1x2u2Ffj+fIhuHZp4Xdd8qqOnbfQ7k26d/4q2JpFCNwuWDhZil2CLOr LJsjwCoNAq+2ac3QVbc0anfNifXLAFnwfLn5aEOGjVC2Pwi/T3aAFS0FzUflt5ZfS8CT tnppqeXninMX2TADQdmwCfpds4k2NR0D8Q5A48/e9HsvWhOKjCT+GW100OLwOitiTy3s zVgeTug41eVEh+xuAHkMg+7UdpDkdZkFC0xyrtGAPxqZ9mFjCleK/BTN8E5R6r8cFU1N PcQg==
X-Gm-Message-State: AKGB3mJ5D6PKFKOq/utzJMwca2CDjWoRBo8SSS7nkIYbiqLdRystDRA2 OeUjKuDBKuz3i4PVfEsISgUT3LuV1BuHxRVI12x+4w==
X-Google-Smtp-Source: ACJfBostWONmImSa0bRF4Tv9n4Uj2WjRv9OlrqN+MiLzm+Rf+4ry+ilg4XI0Y4fWxz654pCN2LNwJCe2yNfc7zEYLhc=
X-Received: by with SMTP id n38mr8853652qtf.42.1513125136957; Tue, 12 Dec 2017 16:32:16 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 12 Dec 2017 16:32:16 -0800 (PST)
In-Reply-To: <>
References: <> <20171209123023.GA8296@pinky> <>
From: Victor Vasiliev <>
Date: Tue, 12 Dec 2017 19:32:16 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a113b51244aba2b05602de67d"
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt
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, 13 Dec 2017 00:32:21 -0000

On Sun, Dec 10, 2017 at 5:59 PM, Martin Thomson <>

> A codepoint might be premature just yet.
> The idea of using a new handshake message type is to allow someone to
> choose between compressing and not.  But consider the case where both
> client and server support non-intersecting sets.  This negotiation
> would cause failure, but that would be unnecessary.
> You could allow the server to advertise multiple (as the current
> format allows), but in that case, when the server certificate arrives
> and is compressed, the client can't know which compression method was
> used without trialing each.  Similarly, when the client certificate
> arrives, the server can't know which compression method was used
> either.
> I think that the best solution to that problem is to include the
> compression scheme in the Certificate message.  It also suggests (to
> me at least) that modifying Certificate rather than defining a
> CompressedCertificate makes sense, though that might not fit with the
> idea that you transform CompressedCertificate into Certificate before
> putting it in the transcript.

I wrote a PR that splits client and server compression negotiation, and
moves the compression algorithm directly into the CompressedCertificate
message.  The idea is that now you can process this statelessly, i.e.
you don't need greater handshake context to parse a
CompressedCertificate message (helpful for tools like Wireshark and in
general simplifies things).  Also, there is now no "negotiation"  -- one
side just lists the algorithms it support and the other may or may not
send a compressed cert using one of them.

Does this PR address your concerns?

> Or, you could trim the list on the server side to a single value, but
> then you have to deal with TLS 1.3 CertificateRequest more explicitly,
> which is currently not at all addressed.  In that spirit, I would also
> suggest that you describe what happens to a TLS 1.3 Certificate
> message that contains extensions (the entire thing is wrapped up as a
> whole, I assume).

Indeed.  This is why the draft compresses the Certificate message, as
opposed to just the certficiates themselves (to cut down the redundancy
in OCSP and SCT messages).

> In light of the changes, this seems like a bug:
>    If the server chooses to use the cached_info extension [RFC7924] to
>    replace the Certificate message with a hash, it MUST NOT send the
>    compress_certificates extension.
> The server could send the extension to allow the client to compress
> even if it had a cached certificate.

Yup.  The PR above removes this entire section, since the server no
longer sends the extension to opt into compression.