Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

Adam Roach <adam@nostrum.com> Mon, 12 March 2018 22:46 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6712422F; Mon, 12 Mar 2018 15:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4wFVxC_AZo4; Mon, 12 Mar 2018 15:46:17 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457D4127010; Mon, 12 Mar 2018 15:46:17 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2CMkF4g031332 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Mar 2018 17:46:16 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Sean Turner <sean@sn3rd.com>
Cc: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>, draft-ietf-tls-tls13@ietf.org, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
References: <152041310032.17609.1489959489741770597.idtracker@ietfa.amsl.com> <CABcZeBM+uRTww=dZsQnwxyFA07nD-iifU-10O5u_bRqAAy39PQ@mail.gmail.com> <ef9df2f2-b7f9-8a41-36a2-a287efa2dadf@nostrum.com> <0BAD6FF1-8E6E-4C43-B1A7-6BC69211C16E@sn3rd.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <300f4b0e-f0a3-111d-306b-02de1e81b5a1@nostrum.com>
Date: Mon, 12 Mar 2018 17:46:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <0BAD6FF1-8E6E-4C43-B1A7-6BC69211C16E@sn3rd.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/w8pMdxKR0nC_X9oXOxoCYirkY8A>
Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2018 22:46:19 -0000

On 3/12/18 5:33 PM, Sean Turner wrote:
>
>> On Mar 12, 2018, at 19:58, Adam Roach <adam@nostrum.com> wrote:
>>
>> On 3/7/18 12:58 PM, Eric Rescorla wrote:
>>>>>   -  TLS SignatureScheme Registry: Values with the first byte in the
>>>>>      range 0-253 (decimal) are assigned via Specification Required
>>>>>      [RFC8126].  Values with the first byte 254 or 255 (decimal) are
>>>>>      reserved for Private Use [RFC8126].  Values with the first byte in
>>>>>      the range 0-6 or with the second byte in the range 0-3 that are
>>>>>      not currently allocated are reserved for backwards compatibility.
>>>> Unless I misunderstand the compatibility mechanisms here, the reservation of
>>>> first byte=0-6 seems to assume that no further assignments will be made from
>>>> the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the case, I
>>>> would expect the IANA considerations section to include a request that the IANA
>>>> close the table to further registrations. The same comment applies to TLS
>>>> SignatureAlgorithm Registry.
>>> Agreed, but I'd like to hear from the chairs.
>>
>> I think we're still waiting to hear from the chairs on this topic.
>>
>> /a
> I think this got lost somewhere in the flurry of emails:
>
> See s17 of https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> We don’t close the registry because technically, if somebody really, really wanted to they could register values for earlier versions.

Ah, thanks for the pointer. I don't agree with your evaluation that 
draft-ietf-tls-iana-registry-updates preserves the ability to register 
values for earlier versions, as it marks all remaining available 
codepoints "reserved." That's effectively equivalent to what I'm asking 
for, though, so my comment is addressed. There's still a potential mess 
brewing for the HashAlgorithm codepoints 224 though 253 colliding with 
SignatureScheme values of 0xE000 - 0xFDFF, but it seems pretty unlikely 
that SignatureScheme allocations will reach that point before 1.2 and 
previous versions disappear.

/a