Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Eric Rescorla <> Thu, 31 May 2018 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86EBC12EC72 for <>; Thu, 31 May 2018 07:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 j5Vx0zI_U2m0 for <>; Thu, 31 May 2018 07:51:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED5E012ECC2 for <>; Thu, 31 May 2018 07:51:27 -0700 (PDT)
Received: by with SMTP id 101-v6so3111541oth.4 for <>; Thu, 31 May 2018 07:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1b1D2A3Xor7+q/ST2vlPjJYN8jIyw2tXMsUdsC1m16I=; b=IJJAp938q5Hs+70n+an/cPh3BDEihHjDOHUfSsiIq13pv+seshIjys5+2tUuRfbxf+ lYpAX+YmbPbkVaMNAX/iFrTEoUO4jv4OlO1V0NdFcKhc9QqKtudKcYH5QKkzb93J92he nwxh+ObZkhNiSESEZdYZMfd7Cebsb8XnX/tpHoQjYOSCEB1gn76ekXPqdHv1V4+wG7RB Y6uIHluioKKtU6D7aTXQlMTWg+Qai/Jyd6KfdobBk61Fs8L/bD0RwblQFPZ8T2Rd2DCe OhcijRW+4KWnaT7BhV8Nko/BZWNBtzn7I/1pDhohlxVkvzwNj1KGMArHSZ1Zr+5TtDlE T8hQ==
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=1b1D2A3Xor7+q/ST2vlPjJYN8jIyw2tXMsUdsC1m16I=; b=T0tlM0uyESps6RUB8p4dz744jA+QbANlGPyEqdSuC0HAYwTQw2Ct+qMBVzZ0K5+Bf/ JHmhCXIQ7PNkoC6YLOIg0xeT2vYcPo8HkM+4ui8wEeMMGktLAQfh193f5Sk+gJWF6hqb mS26gDeKlymSPUwv4tgDhyXUdgxRVrqyQXs1QbZHzd/yOltOIUSJqizFp8e+C8UQbfe8 tTrCa2ciS/9BHpGr+yV8/nlWhTDvP9+wYWhSU79wOYmxyJpmZzFfAsd8aSDhiBiRBEw+ R6mEIKAv1x29Jk0Bz8guVH6ZeyuTJyYsi8le31s9ZQQUZYTvZ/NTGRRxCCZtn29idntE VXEA==
X-Gm-Message-State: ALKqPwcbHCG0mx86CUnNJqm+YsbJ8vh+ZbMFQmZ95ovtBA6KJ3MePp7Z z4KniwvqHqHZLquvmIm2gTFz3Ugq1GIUxyJiUW1K8w==
X-Google-Smtp-Source: ADUXVKKBSFIm0CVv1TZATU2Im1dBnZH+uuZIET1ABELbpRh77owyT7WA4zP6nE/v7coBWilbLf1j200QNPwG0mFvbWU=
X-Received: by 2002:a9d:5917:: with SMTP id t23-v6mr4988276oth.217.1527778287344; Thu, 31 May 2018 07:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 31 May 2018 07:50:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 31 May 2018 07:50:46 -0700
Message-ID: <>
To: David Benjamin <>
Cc: Joseph Salowey <>, Adam Langley <>, tls-chairs <>, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000001cf0fd056d819ac0"
Archived-At: <>
Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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: Thu, 31 May 2018 14:51:36 -0000

Based on this, I propose that IANA allocates a new !26 Early Data code
point for compressed certificates (that's mechanical).

As noted earlier, it's premature for TLS-LTS to request a code point
because the enabling document has not yet been published, so we can defer
the question of its use of 26 for a bit.

The QUIC TLS extension should also change to a new code point, but I'm not
sure it meets the criteria for an early code point assignment. MT proposed
just squatting on a random code point. Having a really unique code point is
less important here because this extension will only appear inside of QUIC
and not on ordinarily TLS connections, though of course it must have a
unique code point from other extensions used with QUIC. So it's not
entirely clear how best to handle this,


On Thu, May 31, 2018 at 7:42 AM, David Benjamin <>

> I probed a bunch of servers yesterday and found evidence of yet another
> collision at 26! It's possible these are TLS-LTS implementations, but a lot
> of them additionally only support RSA decryption ciphers, which makes this
> seem unlikely. These servers do not appear to do anything with the
> extension, as far as I could tell, including even echoing it back, but
> they  send decode_error if the extension includes a non-empty body. (It's
> possible their TLS implementation supports TLS-LTS, unconditionally parses
> the extension, but does not actually enable it by default.)
> I didn't repeat the probe with 27, but playing with a couple of the
> servers showed they tolerate other numbers fine, including 27. It's just
> that they appear to have squatted on 26 for something.
> It's frustrating that allocating code points is complicated, but given the
> other deployment problems TLS has seen lately, were this the worst of our
> problems, I would be quite happy.
> On Thu, May 31, 2018 at 1:56 AM Joseph Salowey <> wrote:
>> I agree we should use a different number than 26 for certificate
>> compression.  I don't see a problem with assigning 27 and reserving 26 for
>> now.
>> On Wed, May 30, 2018 at 8:13 PM, Adam Langley <>
>> wrote:
>>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <>
>>> wrote:
>>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
>>> > working group for their smart locks last year. I have no idea how much
>>> > of the code they are going to reuse (if any at all).
>>> Chrome / Google is blocked on code-point assignment for deploying
>>> certificate compression. It appears that 26 is not a good pick and we
>>> thus wait in anticipation for a replacement.
>>> (The extensions space is effectively infinite: if we get close to
>>> running out, we can assign an "extended extensions" code point, which
>>> would contain a nested extensions block with 32-bit numbers instead.
>>> Therefore effort and delays resulting from treating it as a scarce
>>> resource are saddening. Speaking in a personal capacity, it looks like
>>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
>>> randomly to avoid issues with concurrent applications and I offer
>>> 0xbb31 as a high-quality, random number. Since we had a triple
>>> collision in this case, random-assignment's virtues are currently
>>> particularly clear.)
>>> --
>>> Adam Langley
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list