Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates
Benjamin Kaduk <bkaduk@akamai.com> Mon, 26 March 2018 17:18 UTC
Return-Path: <bkaduk@akamai.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 B8228126B6E for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 10:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 fbvGl6g8bWex for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 10:18:09 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04BA1201F2 for <tls@ietf.org>; Mon, 26 Mar 2018 10:18:09 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2QHEP7X021519 for <tls@ietf.org>; Mon, 26 Mar 2018 18:18:09 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=vzWankDS8VstB2kqP43EyDgQ8/yIL7aFh1hLRQWOUi4=; b=XWpgQngWCPLf1vIYjI+E7Eqf8j3C4oLj5z0TcwV+ADwTQkuGNaRS+cdkQlw4eERR576l mDSfHz3WNWzFJmpiggXmL9WAZoxEx8rdJoe8jd7cZo2X3MzrIAxuyjy7RNY3sej2LfIo xA5fCdzYD/04wWgF/Qv/QamwNXn6z5Cp35vVVhn6EXdVDIIM4kg4zl2zM3p0kiVDirCT pKJw9ehVIBqwPRP6fKLRFbDKfvVf8IDtWn8klaDDEwwJRaRdNuK0TUlS764G65SsA8wv PK7Mi/BdgMvzURFq9JOkZ7S2ZnrjjEa5vFUTfbG3df0CudSkKgipkC6cOxzbNnNicSLl YA==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2gwj5yd8wv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Mon, 26 Mar 2018 18:18:09 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2QHFv5A025451 for <tls@ietf.org>; Mon, 26 Mar 2018 13:18:08 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2gwj0w70pd-1 for <tls@ietf.org>; Mon, 26 Mar 2018 13:18:07 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 186A483E32; Mon, 26 Mar 2018 17:18:06 +0000 (GMT)
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
References: <505FCF83-C92E-4A90-83BF-4B2C4796EBE6@sn3rd.com> <77875DAA-EE63-4EBA-8951-61F89D9FBAD8@sn3rd.com> <1521713417877.45777@cs.auckland.ac.nz> <21D7BBB3-5B19-4721-B08A-9AD887F37F99@sn3rd.com> <EBD5C0A9-FE81-4823-BDBA-88F575467B97@akamai.com> <20180323125758.GE25919@kduck.kaduk.org> <FE8B999F-6A3D-4E7F-93A2-A8A2A20C5BED@akamai.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <ef364e4b-d8bc-c8fe-5d2a-0e78fb30631c@akamai.com>
Date: Mon, 26 Mar 2018 12:18:06 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <FE8B999F-6A3D-4E7F-93A2-A8A2A20C5BED@akamai.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-26_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=946 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260179
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-26_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=920 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260178
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cC5AjvftlFWnCnpF9lIy4XZVWWw>
Subject: Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates
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, 26 Mar 2018 17:18:12 -0000
On 03/23/2018 07:59 AM, Salz, Rich wrote: > So we have two registries that share a number space. > > Sounds like the right solution is for the registries to coordinate. > Well, there are three registries involved -- two existing one octet registries that apply to TLS 1.2 and below, and a new TLS 1.3 registry with two octets of space. The original proposal by the authors was to mark all the unallocated entries in the existing two registries as either reserved or deprecated. IANA noted that this is effectively the same as closing the registries in terms of the difficulty of making further registrations, though I am not sure that the authors replied to the question that I think I asked about what the procedure is for re-opening a registry should a need arise to allocate an additional codepoint from it. Anyway, it seems rather challenging to try to keep all three registries open and coordinate amongst them, given that the new two-octet registry has a pretty low "specification required" registration policy, and allocations from the existing registries would apparently both require a "contiguous" 256 values to be free in the new registry and then "knock out" those 256 values from further use. This would eat up the free space in the new registry relatively quickly, and presumably would not be compatible with a weak "specification required" policy (which is currently the policy for values 64-223). If we agree that "specification required" is not appropriate for the existing one-octet registries in a proposed "coordinate" scenario, then I don't see what the policy would be other than "standards action" (the current policy for values 0-63). And if "standards action" is the bar, that would require the IETF to do work on TLS 1.2 in order to need a new registration, but this WG is chartered primarily for TLS 1.3 and "require significant justification" to take on work for older versions. So it's extremely unclear to me that there's a plausible scenario in which a registration in the existing registries would occur. Such a case could presumably reopen the existing registries for its use anyway, given the level of review that would be needed. So, in summary, closing these registries seems to adequately reflect (my understanding of) our expectations for what will happen to them. I'm curious to know how your understanding differs. -Ben
- [TLS] Additional changes for draft-ietf-tls-iana-… Sean Turner
- Re: [TLS] Additional changes for draft-ietf-tls-i… Benjamin Kaduk
- [TLS] (crypto agility may benefit from private ex… Rene Struik
- Re: [TLS] (crypto agility may benefit from privat… Eric Rescorla
- Re: [TLS] (crypto agility may benefit from privat… Rene Struik
- Re: [TLS] (crypto agility may benefit from privat… Eric Rescorla
- Re: [TLS] Additional changes for draft-ietf-tls-i… Sean Turner
- Re: [TLS] Additional changes for draft-ietf-tls-i… Peter Gutmann
- Re: [TLS] Additional changes for draft-ietf-tls-i… Sean Turner
- Re: [TLS] Additional changes for draft-ietf-tls-i… Salz, Rich
- Re: [TLS] Additional changes for draft-ietf-tls-i… Benjamin Kaduk
- Re: [TLS] Additional changes for draft-ietf-tls-i… Salz, Rich
- Re: [TLS] (crypto agility may benefit from privat… Alex C
- Re: [TLS] Additional changes for draft-ietf-tls-i… Benjamin Kaduk
- Re: [TLS] Additional changes for draft-ietf-tls-i… Salz, Rich
- Re: [TLS] Additional changes for draft-ietf-tls-i… David Benjamin
- Re: [TLS] Additional changes for draft-ietf-tls-i… Benjamin Kaduk
- Re: [TLS] Additional changes for draft-ietf-tls-i… Salz, Rich
- Re: [TLS] Additional changes for draft-ietf-tls-i… Sean Turner