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

"Dan Harkins" <dharkins@lounge.org> Mon, 04 April 2016 14:36 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 A1EEE12D732 for <tls@ietfa.amsl.com>; Mon, 4 Apr 2016 07:36:36 -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 gelM5__4fVqG for <tls@ietfa.amsl.com>; Mon, 4 Apr 2016 07:36:35 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFA12D730 for <tls@ietf.org>; Mon, 4 Apr 2016 07:36:35 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BF5711022404C; Mon, 4 Apr 2016 07:36: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:36:35 -0700 (PDT)
Message-ID: <fa7284ff7f22aa724fbdc7122707c0e3.squirrel@www.trepanning.net>
In-Reply-To: <CACsn0cmM+YTkPKf-nbqgyq=GdG=8M7i+Jq1a-kx77C9CbWCwqg@mail.gmail.com>
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> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <CACsn0cmM+YTkPKf-nbqgyq=GdG=8M7i+Jq1a-kx77C9CbWCwqg@mail.gmail.com>
Date: Mon, 04 Apr 2016 07:36:35 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Watson Ladd <watsonbladd@gmail.com>
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/i0dFagm6UXUQ88BKv9TsO16Xje0>
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: Mon, 04 Apr 2016 14:36:37 -0000


On Mon, April 4, 2016 7:17 am, Watson Ladd wrote:
> On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins <dharkins@lounge.org> wrote:
>>
>>
>> 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.
>
> Why can't embedded devices use certificates?

  Code bloat for a one-off enrollment protocol, no way to authenticate
to obtain the certificate, and the continued lack of that Global PKI
that was supposed to take care of everything and that is currently 20
years late in being delivered.

  Actually, that's not quite right. Some do use certificates...wrongly.
Usually what happens is the server generates a self-signed certificate
and the apps are given some "username" and "password" and the app
ignores the unauthenticated nature of the TLS connection and sends
the u/p credential on through.

  Dan.