Re: [TLS] Request to register value in TLS extension registry

Benjamin Kaduk <bkaduk@akamai.com> Wed, 03 October 2018 17:19 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 B72AC127148 for <tls@ietfa.amsl.com>; Wed, 3 Oct 2018 10:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 hVNc_MMffuYy for <tls@ietfa.amsl.com>; Wed, 3 Oct 2018 10:19:53 -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 A31F31252B7 for <tls@ietf.org>; Wed, 3 Oct 2018 10:19:53 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w93HH9fw006956; Wed, 3 Oct 2018 18:19:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=/NC2k1ydDnWvhxcsZraX/b5TO3LV3dBaQgrDw+0GN6c=; b=HlubkuyGd+GiubIZb6CUd51aepF2rRoP+CNi5yU9Tu1tVBncYDkjMGo+muoIO543eD3b Y2vi6ZxSnHpE5TdcM1ham9IjWLAXhOuv6Fhi8Am1jPeqHxsM5SxFr1Bu0ygFSIjgQKLp bU8ccBck4BU6XU6GbGt1VSCjeYhqlYJIhsXXqAgL131ebayfzdlgUO8y85WRl7uLCnex bOfv5HBvA0bIpekKjh1hrVP+bsLgMFbfb87c8423tHF4xU6HnfyWara5mz+/39YIVV/J W57slLIIg+tSJLgySgS+GdO958nAByRkHJ1mJ/vQUd5+wXNeGhKK4qHAZuxk3P1fka5/ /A==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2mvgu2ttrt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Oct 2018 18:19:50 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w93H5GZN007327; Wed, 3 Oct 2018 13:19:48 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2mt4qvbcvx-1; Wed, 03 Oct 2018 13:19:48 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 98B652099F; Wed, 3 Oct 2018 17:19:48 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1g7koN-0005Lg-Vn; Wed, 03 Oct 2018 12:19:48 -0500
Date: Wed, 03 Oct 2018 12:19:47 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20181003171947.GT19845@akamai.com>
References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com> <20181002141336.GN19845@akamai.com> <1538547426940.37433@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1538547426940.37433@cs.auckland.ac.nz>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030161
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030163
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8ct1sYjMeWtwzvrc85XLn4sadIs>
Subject: Re: [TLS] Request to register value in TLS extension registry
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 03 Oct 2018 17:19:56 -0000

On Wed, Oct 03, 2018 at 06:17:09AM +0000, Peter Gutmann wrote:
> [CC'd back to the TLS list because this affects other TLS work as well]

(I responded privately to Peter about this already.)

> Benjamin Kaduk <bkaduk@akamai.com> writes:
> 
> >Having looked a bit harder, it seems that perhaps I need to point out that,
> >if you want IANA to allocate a value, you need to *ask IANA for it*.  The
> >tls-reg-review@ietf.org list is not a supported IANA entrypoint;
> 
> That's not what the RFC appears to say:
> 
>    Specification Required [RFC8126] registry requests are registered
>    after a three-week review period on the <tls-reg-review@ietf.org>
>    mailing list, on the advice of one or more designated experts.
> 
>    [...]
> 
>    Registration requests sent to the mailing list for review SHOULD use
>    an appropriate subject (e.g., "Request to register value in TLS bar
>    registry").
> 
> This is exactly what I did, I sent a registration request to the list for
> review.

I'll note that there is a different interpretation of the text of the RFC,
namely that it is guidance to IANA, not guidance to those requesting codepoints.
(In particular, the IANA Considerations section says that the whole document
is IANA considerations.)

IANA is the authoritative source for both the numbers in the registries
and what the registration procedure is for getting new allocations; they have
full-time professional staff to answer questions and an SLA.  If you're
uncertain of the process, asking them seems like a great plan, rather than
assuming you will guess correctly.

Interestingly, https://datatracker.ietf.org/list/nonwg only has three other
foo-reg-review lists, one of which has something funky happening with the
MHonArc archivs.  The other two have some pretty sparse traffic, but all
successful requests do seem to end with someone actively sending mail to IANA.
That is, IANA is not monitoring the list so as to take action.
I suppose if you want to count on the kindness and organizational skills of
the volunteer experts and have them remember to tell IANA about the end of a
review period, you could do that ... or you could tell IANA yourself and
be sure that they know.

I'll also give some general background that the whole reason we have
designated experts is to provide the technical advice that IANA does not have
in-house, as needed by certain registration policies.  For Standards-Action,
the technical expertise is wholly delegated to the IETF; for RFC-Required, the
IETF/IAB/ISE.  FCFS requires no expertise at all, but Specification-Required
and Expert-Review need the experts, to provide guidance to IANA on technical
questions.  Nonetheless, it's still IANA making the registration, just acting on
the advice of the experts.  My advice remains: talk to the professionals
first.


>    Within the review period, the designated experts will either approve
>    or deny the registration request, communicating this decision to the
>    review list and IANA.
> 
> This never happened.

I don't think you actually had enough public data when you sent this to be
confident it was true.  After all, the experts could have sent the decision to
IANA and IANA dropped it on the floor.

> Did anyone actually test RFC 8447 before it was published?  You send a request
> to a mailing list that doesn't seem to work, to be reviewed by a secret panel
> (well, we know that Rich Salz is one member :-), with no public discussion or
> list archives you can examine to see what happened, and in my case no response
> to the registration request submitted as per the RFC.

Sean has already clarified much of this.  But I'm curious; if you think you
have followed the proper procedure, why did you not act on the escalation
procedure I pointed out to you previously, rather than continuing to complain
on the TLS WG list?

-Ben