IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Wed, 30 March 2016 20:28 UTC

Return-Path: <ynir.ietf@gmail.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 D362612D832 for <tls@ietfa.amsl.com>; Wed, 30 Mar 2016 13:28:35 -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, FREEMAIL_FROM=0.001, 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=gmail.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 zm3WYJ2GqckX for <tls@ietfa.amsl.com>; Wed, 30 Mar 2016 13:28:34 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 332F012D92A for <tls@ietf.org>; Wed, 30 Mar 2016 13:26:54 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id 20so86556087wmh.1 for <tls@ietf.org>; Wed, 30 Mar 2016 13:26:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ovoUtamn+oeUq0zend3bqF5whZ2dBdZR+h3qKBB1RTo=; b=oj5hkQHfQldCQssQ+WVqtpKTqI5UN8BQqZaWdvsxy34lFkhV1jdoFC5iHALk976oCo rYt8b3pkv8RzHxd7rVFomp8Qoks7wVKP+LkcBkVjrqijPFNW81TDPtsuxuFBIvtAPXEb pcsaqjU5mTbEIDVa3sD1G9iVx8YD3RXUNKzUmBODMEW/FBWkZOMcjumxtkjBCvli3D2e dimA5jxllow/hypm1Dbiu3lAB7dJ7t3eT5GpF42ljvX9nHDcbU9bhBo1cBS+D/IWpveW KDQUzBeOSc5sP/xZfjN/BIrJUg5SgyqXkulCymrOWXM/4cwEz6Fr8+m7KOmzb+BNJ2mg o3Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ovoUtamn+oeUq0zend3bqF5whZ2dBdZR+h3qKBB1RTo=; b=ASrMGHJ4nKPtj7/jJ37NDvWEu+Cbhf2A/CB8YxJWXYlSZUiUCkJknPSZCY6gbYXa4Q 2Y+z2A/cE7XcXofsVBEJFSl3B8VWek+rJExgvmnjugfQI0iRna+9KNNH3JxxWsfnEw1j ya5dU7eFHriXSbBiNgtrlSscjGWI8FDVki2N1/bFB5Pvt82MLq1Gf9dZuEMvKEbxnB0w iZ2WYaraWg6/5NN44lfpoYtdV5OTBSku/ERUAL9RoCBZglMugaIRDQZrvVP82kU2oN8Q y8lFKx/q4EOIUuJWtrAVxSF8GttOKWmMGB++kpiDS1GGIUEB6D0cq6uQq06IEOiVyeRz PShg==
X-Gm-Message-State: AD7BkJIScudBTADhzkXWR8t0+1Gu15TJwcynoGETsWM3AINPP5XdjKyVlUXPcmucxcEmHQ==
X-Received: by 10.28.35.86 with SMTP id j83mr3715429wmj.25.1459369612728; Wed, 30 Mar 2016 13:26:52 -0700 (PDT)
Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ls5sm5570756wjb.33.2016.03.30.13.26.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:26:51 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_DAE46F9A-20AD-4A90-BFE2-D76009571257"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <87egarbvic.fsf@alice.fifthhorseman.net>
Date: Wed, 30 Mar 2016 23:26:10 +0300
Message-Id: <F7468161-DC32-47E8-97F9-0680D344115A@gmail.com>
References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> <87egarbvic.fsf@alice.fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wOE4BJLuWnzez8uN4JtLFbeqM14>
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 20:28:36 -0000

> On 30 Mar 2016, at 10:44 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote:
>> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
>>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
>>>> I am not sure that we want to be in the business of explicitly marking
>>>> things as insecure other than our own RFCs, though -- there could be an
>>>> implication of more review than is actually the case, which is what this
>>>> proposal is trying to get rid of.
>>> 
>>> I think i agree with Ben here: if we have a tri-state:
>>> approved/not-approved/known-bad, then the people will infer that the
>>> not-approved ciphersuites are better than the known-bad ones, which
>>> isn't necessarily the case.
>>> 
>>> I think i'd rather see it stay at "approved/not-approved"
>> 
>> Then how should ciphersuites with explicit diediedie RFCs (currently
>> RC4) be presented?
> 
> i'd say that they are "not-approved", clearly. :)

That brings up another question. How do things move from “approved” to “not-approved”? Does it require a diediedie document? What happens when we decide that 3DES is just too limited and there’s not good reason to use it, but there’s really no security issue with using it?

Yoav

v2.23.0 | Report a Bug | By Email