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

"Dan Harkins" <dharkins@lounge.org> Tue, 05 April 2016 16: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 838B912D76A for <tls@ietfa.amsl.com>; Tue, 5 Apr 2016 09:36:07 -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 vLRYsTZhfHka for <tls@ietfa.amsl.com>; Tue, 5 Apr 2016 09:36:05 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 079C712D762 for <tls@ietf.org>; Tue, 5 Apr 2016 09:36:03 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 265C0A888014; Tue, 5 Apr 2016 09:36:02 -0700 (PDT)
Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 5 Apr 2016 09:36:02 -0700 (PDT)
Message-ID: <89f6e678df72e2aa000d71c8017782dc.squirrel@www.trepanning.net>
In-Reply-To: <CAMfhd9WGDWMcMUhpSNH+Ay936ZXGEL0RGegZvopWnmCMRQMXTw@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> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> <CAMfhd9XZ_KHhnMMwiE5UkwdXLXDfuy-1xVYMB3YgRg-qDnafjA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C38F7B@uxcn10-tdc05.UoA.auckland.ac.nz> <CAMfhd9WGDWMcMUhpSNH+Ay936ZXGEL0RGegZvopWnmCMRQMXTw@mail.gmail.com>
Date: Tue, 05 Apr 2016 09:36:02 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Adam Langley <agl@imperialviolet.org>
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/0trI77dnxbpoxTKkrn-goi-baFE>
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: Tue, 05 Apr 2016 16:36:07 -0000

On Tue, April 5, 2016 7:42 am, Adam Langley wrote:
> On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
>> How hard can it be to implement TLS-PSK?  I did it in a few hours in my
>> crypto
>> library.
>
> This is getting off topic (which is my fault) but, for us, it wouldn't
> be "just" implementing PSK.
>
> We would need to evangelise it sufficiently with enough vendors to
> make sure that it would be used and that we were building the right
> thing. (The solution might well not be just using PSK). Then we need
> to implement it and get the UI right, try and get other browsers to
> implement it, write specs, write test suites, write sample code for
> all the vendors, deal with the resulting bugs in implementations and
> many smaller things besides.
>
> That's not to say that we wouldn't be willing to put the effort in,
> but the demand hasn't been evinced yet.

  Don't bother. It's unlikely to be used in a browser. This just
underscores the point I was making that people use TLS differently
for different things and the requirements are not the same. Just as
it doesn't make sense to force a browser to implement a PSK (or PAKE)
cipher suite, it doesn't make sense to force some device with a
limited UI that has no interest in accessing random web servers to
use a public key.

  regards,

  Dan.