Re: [TLS] draft on new TLS key exchange

"Dan Harkins" <dharkins@lounge.org> Thu, 06 October 2011 02:14 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 C5E4B21F8CC4 for <tls@ietfa.amsl.com>; Wed, 5 Oct 2011 19:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Level:
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3ZqiRLx6JlA for <tls@ietfa.amsl.com>; Wed, 5 Oct 2011 19:14:03 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 265B921F8CC1 for <tls@ietf.org>; Wed, 5 Oct 2011 19:14:03 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7806D1022404C; Wed, 5 Oct 2011 19:17:12 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Oct 2011 19:17:12 -0700 (PDT)
Message-ID: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net>
In-Reply-To: <E1RBd5l-0000Hy-7O@login01.fos.auckland.ac.nz>
References: <E1RBd5l-0000Hy-7O@login01.fos.auckland.ac.nz>
Date: Wed, 05 Oct 2011 19:17:12 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
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
Cc: tls@ietf.org, dhalasz@intwineenergy.com
Subject: Re: [TLS] draft on new TLS key exchange
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 06 Oct 2011 02:14:03 -0000

On Wed, October 5, 2011 6:49 pm, Peter Gutmann wrote:
> "Dan Harkins" <dharkins@lounge.org> writes:
>
>>  TLS-PSK: resistance to dictionary attack
>>  TLS-SRP: elliptic curve support, divorcing domain parameter set from
>>     the password
>
> So it's a proposal that adds a few obscure geeky features to two existing
> mechanisms that vendors have already decided not to adopt (wrongly, in my
> opinion, but that doesn't change the lack of adoption).  Why would they
> suddenly rush to support this one if they've ignored the other two (and a
> string of earlier drafts along the same lines)?

  This came out of some discussions around security for "smart energy"
applications whose specifications do much hand waving and assume that
certificates magically appear on the most unlikely of places and are
all used properly. They also make it highly problematic for any
off-the-shelf device that is supposed to be integrated into a network
of other "smart energy" devices from working properly. They assume an
unrealistic level of security clue on the people installing and
provisioning the device. Having Joe Random enter a simple password on
the UI of his thermostat, for instance, is much more believable.

  Also, this is the same key exchange used by 802.11 mesh networks to
secure traffic going across the mesh, as well as traffic to create and
maintain the mesh (e.g. routing). Using the same key exchange to secure a
management interface (i.e. a TLS-protected connection to the GUI or a
UI) of a mesh networking device would be useful-- conservation of crypto
algorithms, it's straightforward to set a consistent security level
across interfaces, etc.

  As a general purpose ciphersuite, no I don't imagine it will get
much more widespread use than SRP though. But I don't think that's
necessarily a reason to oppose it.

> (As a more general comment, this draft should be, if anything, an
> Experimental
> and not a Standards-Track, given its context).

  I highly doubt that this hopeful stab at a track would be supported
by the ADs. But I can hope.

>>I'm curious why you are not asking the authors of the SEED, Camellia, and
>>Clefia drafts what those drafts give us that the AES ciphersuites don't
>>already do.
>
> Those three are fashion-statement RFCs whose reasons for existence have
> little
> (if anything) to do with security.  Does that mean this draft is also a
> fashion statement?

  No, it's not a fashion statement. I just don't like following a whole
bunch of other people only to have the door slammed in my face. It
does not jibe with my notion of fairness.

  Dan.