Re: [TLS] draft on new TLS key exchange
"Dan Harkins" <dharkins@lounge.org> Wed, 05 October 2011 23:03 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 79FD111E8082 for <tls@ietfa.amsl.com>; Wed, 5 Oct 2011 16:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.071, 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 fUk7tJkZEAh0 for <tls@ietfa.amsl.com>; Wed, 5 Oct 2011 16:03:56 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0821F8CEE for <tls@ietf.org>; Wed, 5 Oct 2011 16:03:55 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D390F1022404C; Wed, 5 Oct 2011 16:07:04 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Oct 2011 16:07:05 -0700 (PDT)
Message-ID: <d096c015393ef5e7683b38bd015cf05b.squirrel@www.trepanning.net>
In-Reply-To: <m2ipo3cfi8.fsf@localhost.localdomain>
References: <ce78cf414ed82d44135ebbb88e32959b.squirrel@www.trepanning.net> <m2ipo3cfi8.fsf@localhost.localdomain>
Date: Wed, 05 Oct 2011 16:07:05 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Geoffrey Keating <geoffk@geoffk.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
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: Wed, 05 Oct 2011 23:03:56 -0000
Hello, On Wed, October 5, 2011 2:09 pm, Geoffrey Keating wrote: > "Dan Harkins" <dharkins@lounge.org> writes: > >> http://tools.ietf.org/html/draft-harkins-tls-pwd-00 >> >> Please take a look. The authors solicit comments. > > It would be helpful to have a comparison between this proposal and > RFC5054, since both protocols appear to have the same aim ("secure > authentication using only a simple, low-entropy, password"). TLS is rife with drafts and RFCs that have the same aim but go about it differently. > Some features of RFC5054 I noticed that could be used to improve this > draft are: > > - RFC5054 requires that the server store only the 'verifier', while > this protocol appears to require storing the plaintext password. > There doesn't seem to be any discussion on the risks of storing the > plaintext password or any mitigations (for example, using a salted > hash of the password instead of the password directly). Yes, I got another comment to add something to the security considerations regarding compromise of the client and server. This draft does not propose any protection against server compromise the way RFC 5054 does. On the other hand, with this scheme one is not required to fix a particular domain parameter set to a user at password provisioning time. This allows for the choice of domain parameter set to be based on the particular ciphersuite the server is proposing to use (and removes a security critical decision from someone-- the person provisioning the password on the server-- who might not have the competence to make that decision). We could add some protection against server compromise by salting the password when it is provisioned and sending the salt in the ServerKeyExchange. The drawback to this is that the salting technique has to be determined at provisioning time, but that's probably not that big of a deal as the technique has no bearing on the security of the underlying key exchange. Thanks for the suggestion! > - RFC5054 already specifies an extension for the user name. I would > suggest using the same extension for this protocol rather than > creating a new one. It's named "srp" though which makes it less desirable. We'll note your suggestion but unless there is strong desire by the WG to change this we'd like to keep it as is. There's 65k extensions available so exhaustion of this resource is unlikely. > - RFC5054 has test vectors, this draft doesn't. Another good suggestion. We'll add some. thanks, Dan.
- [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Geoffrey Keating
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Jean-Marc Desperrier
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Yoav Nir
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Martin Rex
- [TLS] TLS-EAP. Was: draft on new TLS key exchange Anders Rundgren
- Re: [TLS] TLS-EAP. Was: draft on new TLS key exch… Marsh Ray
- Re: [TLS] draft on new TLS key exchange Marsh Ray
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Philip Gladstone
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Dan Harkins
- Re: [TLS] draft on new TLS key exchange Jean-Marc Desperrier
- Re: [TLS] draft on new TLS key exchange Martin Rex
- Re: [TLS] draft on new TLS key exchange Rene Struik
- Re: [TLS] draft on new TLS key exchange Nico Williams
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Nico Williams
- Re: [TLS] draft on new TLS key exchange Peter Gutmann
- Re: [TLS] draft on new TLS key exchange Steven Bellovin
- Re: [TLS] draft on new TLS key exchange Anders Rundgren
- Re: [TLS] draft on new TLS key exchange Steven Bellovin