Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
Benjamin Kaduk <bkaduk@akamai.com> Wed, 30 March 2016 21:11 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 DD74512D95E for <tls@ietfa.amsl.com>; Wed, 30 Mar 2016 14:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.731
X-Spam-Level:
X-Spam-Status: No, score=-2.731 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 jCJnDYg4B6Q5 for <tls@ietfa.amsl.com>; Wed, 30 Mar 2016 14:11:39 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E92A812D959 for <tls@ietf.org>; Wed, 30 Mar 2016 14:11:38 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 352E143347E; Wed, 30 Mar 2016 21:11:38 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 157A043347A; Wed, 30 Mar 2016 21:11:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459372298; bh=UZkYbsi526XKUYtToUeSQ9lXTcNNxnXbFbO8r1i7tDE=; l=3601; h=To:References:Cc:From:Date:In-Reply-To:From; b=xbNmE2Kek6PqV2UNnJlGM44F7BlYNSpkCtAiOhpEl8qg0m+zZmqnQuRL8Qg4J834V bn6F3GrL/E56/YgvddaNf6BlN1DSP0Z9zQmw5KV5Z34jW48TMFck+HZekmKWppAKTM KqZ4MxhHOEAwhNM4+ZVPeeb6EZialwTHR+/DCdyw=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 909911FC88; Wed, 30 Mar 2016 21:11:37 +0000 (GMT)
To: Sean Turner <sean@sn3rd.com>, Yoav Nir <ynir.ietf@gmail.com>
References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <3F32A6CE-DE7F-4230-8077-AE2CC1161235@gmail.com> <F9E7A34E-DFA0-4830-AE03-6F4CE48480BA@sn3rd.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56FC4109.7060600@akamai.com>
Date: Wed, 30 Mar 2016 16:11:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <F9E7A34E-DFA0-4830-AE03-6F4CE48480BA@sn3rd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hQWe9t9FDzqDy4xjSzICGA9FrrU>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Mar 2016 21:11:42 -0000
On 03/30/2016 01:03 PM, Sean Turner wrote: > I apologize in advance; this is about process so it’s long. > It seems correct and reasonably comprehensive. > This definition gives power/discretion to the designated expert (it’s ekr btw). We can: > > a) defer to the expert's judgement (some of what they are to do is in [1][2]), or > b) write some rules for the IANA considerations section that they’ll follow. > > I think that a) has worked in the past and would continue to work in the future, but b) couldn’t hurt. If we go for a) then if the expert is ever unsure, they can just ask the AD/WG chair/community for guidance [3][4]. Beware that the text for b) will be like a bright light for process moths [5]. > I feel like (b) will probably result in a lot of time on the list getting the text "just so"; perhaps that time would be better spent elsewhere. That said, I'm happy to help with the editing of such text... > > > Some other things we should be clear on: > > 1. All of the drafts referenced and the future drafts requesting code points do *not* need to come through the WG. But, I do think drafts that want a “Y” need to come through, and we shouldn’t kid ourselves most folks will want the “Y”. How does this sound (here I assume the algorithms are already published elsewhere i.e., this is just for the assignments): I agree ... the chairs should use their power to turn things away judiciously :) > a) For MTI and “Y” requests, > a.1) requester’s publish individual draft, > a.2) requester’s ask for wg adoption, > a.3) wg chairs do adoption call, > a.4) wg does its thing on wg draft, > a.5) ietf does its thing, and > a.6) iana (assigns #s) & rfc editor (publishes) do their things. > > b) For all others: > b.1) request is submitted to IANA, WG, WG chair, AD, That's "one of the above", I presume? > b.2) request is redirected to designated expert, > b.3) designated experts reviews request: > -- if good-to-go designated expert tells IANA to assign code point (goto b.4) > -- if not-good-to-go for an obvious reasons the designated expert rejects the request with some rationale (and probably lets the sec ADs know about it) > -- if not-good-to-go for all other reasons the designated expert asks (expert's choice depending on the situation) AD/WG chairs/community for guidance > b.4) iana makes assignment and includes the cipher suite assignment specification reference in the registry (and possibly the rfc editor does their thing if an RFC is being published) > > Early assignment rules can still apply to a) and b). Sounds good to me. > 2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue as a WG draft or free Dan to pursue other publication avenues. No opinion at present. > 3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new cipher suites get added. Drafts should only include an “updates” header if we’re modifying the MTIs or we’re adding a new “Y” cipher suite because we only expect all implementations to support these cases. I support this, yes -- long "updates" lists can be annoying for the reader. > 4. WRT language - I’m assuming we’d continue to have English versions of the algorithm specification. > If we are using IANA as a service for the global Internet, it is not entirely clear to me that we need to insist on English versions of the "specification required" document ... though the capabilities of the designated expert might affect what would in practice get approved. -Ben
- [TLS] call for consensus: changes to IANA registr… Sean Turner
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Yoav Nir
- Re: [TLS] call for consensus: changes to IANA reg… Daniel Kahn Gillmor
- Re: [TLS] call for consensus: changes to IANA reg… Dmitry Belyavsky
- Re: [TLS] call for consensus: changes to IANA reg… Henrick Hellström
- Re: [TLS] call for consensus: changes to IANA reg… Benjamin Kaduk
- Re: [TLS] call for consensus: changes to IANA reg… Eric Rescorla
- Re: [TLS] call for consensus: changes to IANA reg… Henrick Hellström
- Re: [TLS] call for consensus: changes to IANA reg… Daniel Kahn Gillmor
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Yoav Nir
- Re: [TLS] call for consensus: changes to IANA reg… Sean Turner
- Re: [TLS] call for consensus: changes to IANA reg… Sean Turner
- Re: [TLS] call for consensus: changes to IANA reg… Ilari Liusvaara
- Re: [TLS] call for consensus: changes to IANA reg… Daniel Kahn Gillmor
- Re: [TLS] call for consensus: changes to IANA reg… Yoav Nir
- Re: [TLS] call for consensus: changes to IANA reg… Dave Garrett
- Re: [TLS] call for consensus: changes to IANA reg… Benjamin Kaduk
- Re: [TLS] call for consensus: changes to IANA reg… Bill Frantz
- Re: [TLS] call for consensus: changes to IANA reg… Rick van Rein
- Re: [TLS] call for consensus: changes to IANA reg… Stephen Farrell
- Re: [TLS] call for consensus: changes to IANA reg… Eric Rescorla
- Re: [TLS] call for consensus: changes to IANA reg… Stephen Farrell
- Re: [TLS] call for consensus: changes to IANA reg… Martin Thomson
- Re: [TLS] call for consensus: changes to IANA reg… Rick van Rein
- Re: [TLS] call for consensus: changes to IANA reg… Hannes Tschofenig
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Dang, Quynh (Fed)
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Benjamin Kaduk
- Re: [TLS] call for consensus: changes to IANA reg… Hannes Tschofenig
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Benjamin Kaduk
- Re: [TLS] call for consensus: changes to IANA reg… Hannes Tschofenig
- Re: [TLS] call for consensus: changes to IANA reg… Benjamin Kaduk
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Eric Rescorla
- Re: [TLS] call for consensus: changes to IANA reg… Hannes Tschofenig
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Hannes Tschofenig
- Re: [TLS] call for consensus: changes to IANA reg… Eric Rescorla
- Re: [TLS] call for consensus: changes to IANA reg… Stephen Farrell
- Re: [TLS] call for consensus: changes to IANA reg… Rick van Rein
- Re: [TLS] call for consensus: changes to IANA reg… Andrei Popov
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Watson Ladd
- Re: [TLS] call for consensus: changes to IANA reg… Salz, Rich
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Peter Gutmann
- Re: [TLS] call for consensus: changes to IANA reg… Watson Ladd
- Re: [TLS] call for consensus: changes to IANA reg… Peter Gutmann
- Re: [TLS] call for consensus: changes to IANA reg… Phil Lello
- Re: [TLS] call for consensus: changes to IANA reg… Kaduk, Ben
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Phil Lello
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Adam Langley
- Re: [TLS] call for consensus: changes to IANA reg… Peter Gutmann
- Re: [TLS] call for consensus: changes to IANA reg… Adam Langley
- Re: [TLS] call for consensus: changes to IANA reg… Dan Harkins
- Re: [TLS] call for consensus: changes to IANA reg… Aaron Zauner
- Re: [TLS] call for consensus: changes to IANA reg… Sean Turner
- Re: [TLS] call for consensus: changes to IANA reg… Dang, Quynh (Fed)
- Re: [TLS] call for consensus: changes to IANA reg… Sean Turner