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

"Dan Harkins" <dharkins@lounge.org> Mon, 04 April 2016 14:05 UTC

Return-Path: <dharkins@lounge.org>
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 4657F12D6EA for <tls@ietfa.amsl.com>; Mon, 4 Apr 2016 07:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 m37Xd0sOmIsI for <tls@ietfa.amsl.com>; Mon, 4 Apr 2016 07:05:36 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0341012D1A3 for <tls@ietf.org>; Mon, 4 Apr 2016 07:05:36 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 81EE01022404C; Mon, 4 Apr 2016 07:05:34 -0700 (PDT)
Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 07:05:35 -0700 (PDT)
Message-ID: <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net>
In-Reply-To: <56FD63B0.2070205@cs.tcd.ie>
References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <ca13e48abd8042c38bc2116bd5574f85@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie>
Date: Mon, 04 Apr 2016 07:05:35 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/krIlcynroBuaK5r1K_s28KmtPD4>
Cc: 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: Mon, 04 Apr 2016 14:05:37 -0000


On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>
> If smaller devices don't use algorithms that can be used to talk to
> random servers on the Internet, then they are choosing to not try to
> get interop. That seems like a shame to me, unless there's a really
> good reason and IMO, mostly there isn't, at the ciphersuite level. I
> would hope we all won't make the GCM/CCM mistake again for example
> (that "we" being roughly some combination of IETF/IEEE folks).

  That's because you incorrectly define "interop" as talking to
random servers on the Internet. This browser-centric mode of thinking
causes you to reject cipher suites that the browser/webserver
community does not have any interest in.

  There are use cases where some app doesn't want to talk to random
servers on the Internet. It wants to talk to a set of specific servers
providing a specific stream of information unique to the app-- think
of some network monitoring or RF-quality app that provides sensing
data to servers and also sucks down neighbor air quality information
as it roams around. There are IoT use cases where devices just want
to talk to each other, not random servers on the Internet.

  The browser community wants 0-RTT; I don't give a damn about 0-RTT.
I want a PAKE (specifically TLS-pwd); the browser community doesn't
give a damn about PAKEs. We are both right. Because we have different
requirements.

> So I think the proposed change here, if it leads to fewer but more
> ubiquitously deployed ciphersuites, will help smaller devices. And I
> do think the IETF recommended column might lead us some way in that
> direction.

  Fewer is better... for one set of requirements, there's no reason to
have umpteen (> 2) ways of meeting the requirements. But to approach
this issue as if there is only one set of requirements (being able
to talk to random web servers on the Internet) is to cram a multiplicity
of differently shaped pegs into the proverbial round hole.

  regards,

  Dan.