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

Michael D'Errico <> Tue, 06 October 2020 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6817B3A0D8A for <>; Tue, 6 Oct 2020 10:00:37 -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 nk-RUvvpu7NP for <>; Tue, 6 Oct 2020 10:00:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19DEC3A0D89 for <>; Tue, 6 Oct 2020 10:00:36 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id F2B1782F5F; Tue, 6 Oct 2020 13:00:34 -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=/6FetdTDbgqy r/RKDj42xAgppeg=; b=V03+1nK0+aOyCiJwOx2Wsg8k+aYvaj47vINNjMwwklZE x5OHXkolR8yJJ6loa7wiSLZWbK4X6xpR/jV9n8IDuJZsg3MXljon41liRHgaZgdA tsuocw04NzQfK//OilgLuns2KbVYSL6yX658pPtjhecr0MEqTA/4N2N4PsnLFg0=
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=TUZaNJ A6zacRuVYlQN6alLRDKdTE0vWfBHOg0CE1W3RHbitK2GnPPAZ5ksJl/AfUaWsA5A 8GURf9PTnQR+Jy+/yISQmQ9nz82qVaGUdfrAEgkBZRwaxNThyO4vRr9QM7AnKlDK VZ3VecI1LSM98z4CVnb4FRh7j6GPZpkWYrOsM=
Received: from (unknown []) by (Postfix) with ESMTP id E7E3A82F5E; Tue, 6 Oct 2020 13:00:34 -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 000C882F5D; Tue, 6 Oct 2020 13:00:32 -0400 (EDT) (envelope-from
To: "Salz, Rich" <>, "" <>
References: <> <> <> <> <> <> <>
From: Michael D'Errico <>
Message-ID: <>
Date: Tue, 6 Oct 2020 13:00:32 -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: 7247F48A-07F5-11EB-9CA4-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 17:00:37 -0000

>>     But if the spec says MUST be minimum length,
>      I would feel compelled to check every one.
> "Be liberal in what you accept" no?

A requirement of MUST in a security protocol usually
means (or at least should mean) that there's a good
reason for the thing, whatever it is, so if you are
not checking it, then bad things can happen.  I try
to heed Postel's advice though, and can sometimes be
more liberal than the spec says if I really know
what the trade-offs are.  With crypto though, I don't
pretend to be expert in it, I'm kind of afraid of it,
and I'm not sure how anyone can claim to understand
it well enough to say, for example, that ECC is so
much better than everything else.  What if it's all
broken?  We're getting rid of everything else that
we know works....

>>     Please don't require minimum length unless
>      security would be weaker without it.
> If the fields are used in digests/hashing/signatures, then it matters.  (The DER/BER comment upthread)

It matters in X.509 certificates because the basic
encoding rules (BER) allow you to specify the same
thing in different ways.  With DER, there is only
one way to encode every element, so everybody will
come up with the same string of bytes and hashes of
those strings will be the same, signatures will
verify, etc.

I haven't read whatever spec cTLS is, but know that
if I decided to implement it someday and there's a
"varints MUST be minimum length" requirement, I'd
assume that it's important and would check for it.
If this is a waste of CPU cycles, then please don't
make it a requirement.