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)

Peter Gutmann <> Mon, 28 May 2018 04:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F86C12E868; Sun, 27 May 2018 21:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 wnAoEXAmy3pU; Sun, 27 May 2018 21:38:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 378E61273E2; Sun, 27 May 2018 21:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1527482328; x=1559018328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GqA3dBCyD2quUWT6Ttd+CW8YabCNgadP7YzBRM1XUWo=; b=zVzSMhffiTDYDGSMt0N9s8b6WAZzgDOHJ7q7S6NtrUyfLonyVQtwh49z 1QWv9EGjZVri7nhuN52XGdlW7EOz3KXaqPCBzkovVc0uD5H6f2vSUJTjs 4e8YmMN7ZdqeLJEF/ij1EzXtF/J7NRKNB//QuA+YRGSSBMMXG4ysu3F7j jvEcmWr7vVHWWkIOQFCgfb73oP6rVF3FuBRowiOeFBMNqyvM6nMlZ3Z3i i5s0KEmcs6xPctwKHwcauCFRe2QtdEgSXw3VD6BTjSGEPiOwi6LUTbdHe Wt1o1tUu/BrYWg69lajNSiwBpWoMwPzCocfmoqPV+bdTIn+XVXJFJzqye Q==;
X-IronPort-AV: E=Sophos;i="5.49,450,1520852400"; d="scan'208";a="13419681"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 28 May 2018 16:38:44 +1200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 May 2018 16:38:44 +1200
Received: from ([fe80::b0d7:2dae:1a32:6ff4]) by ([fe80::b0d7:2dae:1a32:6ff4%14]) with mapi id 15.00.1263.000; Mon, 28 May 2018 16:38:44 +1200
From: Peter Gutmann <>
To: Eric Rescorla <>
CC: "" <>, "" <>
Thread-Topic: [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)
Thread-Index: AQHT9GMg6inI/yD6CECnWE0tqGUgU6RDiQxq//98VACAAY0qOw==
Date: Mon, 28 May 2018 04:38:44 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 28 May 2018 04:38:51 -0000

Eric Rescorla <> writes:

>In any case, I don't think we should assign code point 26 to this extension.
>I recognize that you have existing implementations that happen to use it, but
>that's a result of the unfortunate decision to squat on a code point which
>was right in the way of near future assignments, and those implementations
>can change to the new code point. Of course, it might be useful to add a note
>to implementations of the compression draft as well.

See my previous comment on why it was used, it was only because implementers
needed something to put in their code while I waited for the registry draft to
be published... 

In any case I'm not overly fussed, as long as something gets assigned, just
wanted to point out that -LTS continuing with 26 would avoid having to
document the problem in two different drafts and adding hacks to code to deal
with it.  Given that one use is for SCADA/embedded TLS 1.0-1.2 and the other
is public web TLS 1.3 it's (hopefully) unlikely they'll ever run into each
other, but it'd be less messy if it was done properly rather than through