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