[TLS] call for consensus: changes to IANA registry rules for cipher suites

Sean Turner <sean@sn3rd.com> Wed, 30 March 2016 01:53 UTC

Return-Path: <sean@sn3rd.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 ADBC912DC33 for <tls@ietfa.amsl.com>; Tue, 29 Mar 2016 18:53:19 -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 (1024-bit key) header.d=sn3rd.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 WYDaXk_7hK9M for <tls@ietfa.amsl.com>; Tue, 29 Mar 2016 18:53:17 -0700 (PDT)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE97F12D183 for <tls@ietf.org>; Tue, 29 Mar 2016 18:53:17 -0700 (PDT)
Received: by mail-qg0-x22e.google.com with SMTP id n34so19691620qge.1 for <tls@ietf.org>; Tue, 29 Mar 2016 18:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=GNxu3t9WN1q91CIpwsRxPpPk7zVMQt5bDVIGeZIHnjo=; b=JJefd1ch74TRnkfcssW/8+NYOEyAz82hlaN/Cmyc9d7fTHVLqkUA3IlqVwjiU9phus 9BgPvPS6sSFqRFI61rflgJpRf6PYzLuAw8cBlxeMMLlaD9sAJ4lxR+Lulfe97hVb/ZXf HQLsgVxPyz+cv+nCzxc2CUMVkethB0uFv5obM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=GNxu3t9WN1q91CIpwsRxPpPk7zVMQt5bDVIGeZIHnjo=; b=MlDaiBSUseqs23ca0ELYrBBc0GRYNGdeIh5etcWaW21/Rzl0C97AN5WXhDElmc2aqi EFmpwQT23mGt8dA2rlUaPykKV+KLmifP3ijuP+jFv1/TPFs481dg2ZMvR1CEW6nvav/e QsDjoEzxtxX8SFt4cOVvTMdTkw+2fqXkU7mq9aELmBrQuXhNjvv657mB1jiW59F7fGaR HyFyn4JPstvaedV8MXZjM4StrBsFA8H1I0pRnpCFVqgFNFPuvb/TsNZTiSOa4oE0P6Mm 6g/XUaykJu4rCj+DN9eKDpiFxjdokU8du1PwfxHCjdj+k65dsbVWHBPBETv73sP3lUR7 xsOQ==
X-Gm-Message-State: AD7BkJLq+SF6o8sND36VGrj4QcIvl1zwctckqmXdz/Gzd84PBjKQDVvyuDyVVjdsHW6cFQ==
X-Received: by 10.141.1.87 with SMTP id c84mr7129539qhd.1.1459302796734; Tue, 29 Mar 2016 18:53:16 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id v65sm765162qhc.6.2016.03.29.18.53.15 for <tls@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 18:53:16 -0700 (PDT)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com>
Date: Tue, 29 Mar 2016 21:53:13 -0400
To: "<tls@ietf.org>" <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/eLJ98YAbieIb4SSoV7ciCDcU8ag>
Subject: [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 01:53:19 -0000

Hi!

In Yokohama, we discussed changing the IANA registry assignment rules for cipher suites to allow anyone with a stable, publicly available, peer reviewed reference document to request and get a code point and to add an “IETF Recommended” column to the registry.  This change is motivated by the large # of requests received for code points [0], the need to alter the incorrect perception that getting a code point somehow legitimizes the suite/algorithm, and to help implementers out.  We need to determine whether we have consensus on this plan, which follows:

1. The IANA registry rules for the TLS cipher suite registry [1] will be changed to specification required.

2. A new “IETF Recommended” column will be added with two values: “Y” or “N”.  Y and N have the following meaning:

 Cipher suites marked with a “Y” the IETF has consensus on
 and are reasonably expected to be supported by widely
 used implementations such as open-source libraries.  The
 IETF takes no position on the cipher suites marked with an
 “N”.  Not IETF recommended does not necessarily (but can)
 mean that the ciphers are not cryptographically sound (i.e.,
 are bad).  Cipher suites can be recategorized from N to Y
 (e.g., Curve448) and vice versa.

3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that matches the above so that the same information is available to those who don’t read the IANA considerations section of the RFC.

Please indicate whether or not you could support this plan.

Thanks,

J&S

[0] In the last year, the chairs have received requests for:

PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
JPAKE: not sure they got around to publishing a draft.

[1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4