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