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)

David Benjamin <> Thu, 31 May 2018 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27E3F12DA17 for <>; Thu, 31 May 2018 07:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s-qmLh0bSnWX for <>; Thu, 31 May 2018 07:42:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A24B512E887 for <>; Thu, 31 May 2018 07:42:38 -0700 (PDT)
Received: by with SMTP id e8-v6so28151382qth.0 for <>; Thu, 31 May 2018 07:42:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sGY4LQExqBnrvusfzzu4XPryUMnKYmHSDNif4ibIu1I=; b=huGE+GqlJD8hbUbVHrSICmqdmR/1z/7wToGMSA0TdDWtFbZ2wIU1qJ1Vc0ql8Ln4jU 3tG87DE3JotQaMkBmM7rZEwGdyiY7sI3Nwr7nHklPZv5QxI54Q7aT3WW282Vs8JcFVVf od6YW3Bd9K+fq54bf6e64BaVvUHLBA6weG+30=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sGY4LQExqBnrvusfzzu4XPryUMnKYmHSDNif4ibIu1I=; b=tdSLYHV4mWdg84DdQPnPb78w2dvD6wxVJQgN0lyNcqNyCS4/DaBuXOZd2D4Y5ZJB/z mYYsKhDAHnloH/zHndt/uW/QdjL3fCUNOtCIIy9eYI/cdEVjYaV4yC9jj6QgBJP28t9Y qJYSa/lfQmynA+BkrBfxPQcji8TPWOZ5edg3fjLV2exNt1dRJU/rqrbdttcgvNSRRwlm 4VFFcgO1JnYkjTJ/4aI6iWG3FYFPN8wUn+hsp/CuK7IjMSeaxtjw5vhq0ScEXFbB2oBd I5L1GyrUGkcvlyN/sAcIG9Ly/2d9628LebvvjbAZsor4i0LCyqmnNdZKBx/UhgHgw7YG RgDg==
X-Gm-Message-State: APt69E2LCcJZD4T1u/LXwzY7an8vLWHzyICPMlXwOOXk+cjjpsqjgaDn gbKOtpBvlsww8fWN6TSRzsEzibtBQyQsdvZAbjpw
X-Google-Smtp-Source: ADUXVKIBvgBh22FWKyMdXDMYPgDfTmbNUQvJqs6gtmlCRMnQdrT+BtEpfsYX+pquoqwlg/yRdSJ+cbkdEPyaA/HxbTE=
X-Received: by 2002:ac8:1704:: with SMTP id w4-v6mr1401936qtj.217.1527777757582; Thu, 31 May 2018 07:42:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 31 May 2018 10:42:24 -0400
Message-ID: <>
To: Joseph Salowey <>
Cc: Adam Langley <>, tls-chairs <>, "<>" <>
Content-Type: multipart/alternative; boundary="00000000000089e426056d817a26"
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:42:41 -0000

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