Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Michael D'Errico <> Tue, 06 October 2020 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC293A14D9 for <>; Tue, 6 Oct 2020 11:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a9w4Bx4J95xt for <>; Tue, 6 Oct 2020 11:37:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 545043A14D8 for <>; Tue, 6 Oct 2020 11:37:05 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 8407183B94; Tue, 6 Oct 2020 14:37:04 -0400 (EDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=3q4LD/NagGwp laQWvylwTUrwlLQ=; b=ltzYrYrQmktsIJSrxI3YRmh7cqHhhkWg1AOgfZZxItU1 JnkKdPx1VD89plzXyIwSEs8M74fSXDd+s/6SLxuq2OojsPAvM1RiSjMZUUiwFICG szMALOoHEVZMqXMPEKXnuWT2XLf32NenbirZqWeYK2uX0h4ZM4eO2XgiPi6U39w=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=frXlKT ddrNSiFuYyANY8o9gfSECceAwBffE3jRhEsbh9iN8q+WzK3Adhn7+r2FlQCl3f7p XZq5SJ/T/Levvwps3lsGO9AB4OpwxgPJXF7pFGrEk0uk7ORi/2VMW7s8egDVo26I RRZmy7sHZAwlLAdrdvLTxt/EBmjOGnPqwNbRc=
Received: from (unknown []) by (Postfix) with ESMTP id 7BC5283B93; Tue, 6 Oct 2020 14:37:04 -0400 (EDT) (envelope-from
Received: from MacBookPro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A60E383B92; Tue, 6 Oct 2020 14:37:02 -0400 (EDT) (envelope-from
To: Christian Huitema <>, TLS List <>
References: <> <> <> <> <> <> <> <> <>
From: Michael D'Errico <>
Message-ID: <>
Date: Tue, 6 Oct 2020 14:37:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
X-Pobox-Relay-ID: ED323ACC-0802-11EB-A509-74DE23BA3BAF-38729857!
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
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: Tue, 06 Oct 2020 18:37:08 -0000

I think we are in agreement.

On 10/6/20 13:12, Christian Huitema wrote:
> * Receiver side: receive the message, parser with generic ASN.1 decoder,
> process the message using the "parsed" representation, re-encode with
> DER, check the signature.

I recall that at least one root certificate had a
SEQUENCE encoded using BER-but-not-DER (?)  Yeah if
your software re-encoded that, it would no longer
be the same sequence of bytes.

> Experience showed that this workflow is very problematic, because the
> parse/reencode process may introduce subtle changes and the signature
> will fail.  One may argue that these changes are due to implementation
> bugs, but fact it that this is a rich environment for growing bugs.
> Based on experience, the receiver side is better done as:
> * Receiver side: receive the message, save it, parse and process, and
> when it is time to verify the signature go back to the original message
> and check the signature.

This is how I did X.509 verification, though I was
late to the game and the advice was already there
to accept a BER-encoded certificate.  Not sure if
I would have done the DER re-encoding bit if that
was the current advice at the time since it seems
like the wrong thing to do, but maybe I would have.

> If we do that, then there is no reason to mandate minimal length
> encoding. And TLS already does that. For example, we do not reorder
> extensions according to some canonical rules before placing them in the
> transcript.

I was disappointed to see that the TLS 1.3 spec now
has a requirement to put one of the ClientHello
extensions in a specific place (last in the list).

We discussed this at length during the development
of either TLS 1.2 or one of the extensions (maybe
renegotiation-info?) and we ultimately came to what
I believe was the correct decision never to require
any ordering of the extensions.  Sad to see the
group capitulated to whomever said it would make
their software easier to write (which I doubt).