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

Dave Garrett <davemgarrett@gmail.com> Wed, 30 March 2016 20:32 UTC

Return-Path: <davemgarrett@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 5A89812D832 for <tls@ietfa.amsl.com>; Wed, 30 Mar 2016 13:32:06 -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 FxyLkAjynTsj for <tls@ietfa.amsl.com>; Wed, 30 Mar 2016 13:32:05 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 C618712D0B0 for <tls@ietf.org>; Wed, 30 Mar 2016 13:32:04 -0700 (PDT)
Received: by mail-qg0-x234.google.com with SMTP id j35so49682714qge.0 for <tls@ietf.org>; Wed, 30 Mar 2016 13:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=iHeUfSzNsUb4NTjnUY7tWYzlbsowQaPePrHmKpF25Jk=; b=lOvYp0CDq6BJBlzxHSg4ZExLamAid0S9b5Qo0eZH+cUt2CjXu7HHyL3WC63mJie8PB 1CEdcv+loKJq/3KDKmkX5Tjy0S4ds7SJDjdGe9T67pW3Zlz6gpGRk2nMRdsyO41OcDNZ lBHcH+3TOnmervqfkzhzNL0L7x/EqWDQUawF049qURaNmUThaSu787ChJIQVtAp6Y/U+ GAktgTSNzx3ka9LNwxS06sj7d2GOUrAZz0kNvvSLP/Ynk5QvTBX121NeZUIRQhUaREki G2eNfA9jCuk1fAKqRkAtCoGETErCxvfNfAY1exTngLjIQEwaOdf4T9QqgWsu53T7lMGV qRlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=iHeUfSzNsUb4NTjnUY7tWYzlbsowQaPePrHmKpF25Jk=; b=hnjX0RXPl21ZeCcmTHHcuYhwvUiUyNp3RQRRUBD9dVhg/FF4Ij4v9GtplT+2qSY7Th pPPReamc09Jt9tXWv4QYFzrBSkbjCXT3mf+2tgsxYCo+XDs/vvEHQ0QPx+phBIo8Otlq x83fokebx8LsWGHjh6gu5ebCtMI3eMP+OER8BtKUxC8123Jk9oFMx1qEbnAMFKs3aJL8 ytVjGhUjWBrLSroEfNluoWue9A5xLP8/sWYiLVAeYFO2E4E0R9kxaXtbIh2SGbLJtmra eJRtQp+4XNtdupQcsUFDUTEkSXx7l5UZ+RkxEosTl2c0FGSHJotc7HvjSQ9rMbANGVqb AhCQ==
X-Gm-Message-State: AD7BkJKH+TJ+KzkYMUoPGoyjhtFG5Dn6+McKpkeBFhC/yQ3RSGZPCgwLFuBz4LTVGgtBkw==
X-Received: by 10.140.32.245 with SMTP id h108mr12330819qgh.50.1459369923863; Wed, 30 Mar 2016 13:32:03 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id 139sm2574372qho.2.2016.03.30.13.32.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:32:03 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Wed, 30 Mar 2016 16:32:02 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201603301632.02431.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/RXqX28HvLTQEv91TFaEQVV2i4OA>
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:32:06 -0000

On Wednesday, March 30, 2016 03:20:08 pm 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?

A tri-state that might be more acceptable would be approved/not-approved/amended, where "amended" indicates an RFC released after the initial specification that is considered mandatory. This would be both diediedie RFCs as well as any sort of less severe update, without as much implication that "not-approved" automatically implies safety.


Dave