Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document
Watson Ladd <watsonbladd@gmail.com> Thu, 18 December 2014 01:49 UTC
Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483301A0097 for <cfrg@ietfa.amsl.com>; Wed, 17 Dec 2014 17:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 ezKEpTfL_5XC for <cfrg@ietfa.amsl.com>; Wed, 17 Dec 2014 17:49:23 -0800 (PST)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12311A00C3 for <cfrg@irtf.org>; Wed, 17 Dec 2014 17:49:22 -0800 (PST)
Received: by mail-yk0-f173.google.com with SMTP id 19so116177ykq.32 for <cfrg@irtf.org>; Wed, 17 Dec 2014 17:49:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nRKw7RsMoUm2uzmD+1Yj+o8uhdBjvXAoT4LXihdhqAY=; b=rJBGiz5Ha9UbVe1vCkJxkfm9DCCqADJ/omzxxpd/pxdvxk+TaFJWASoFENBkkaANaG 4IPV9xMsDF7Otsvtf6agIk4xjATGTF4uPFP/3Z/p/4QD4zGcLNpWIn3Eyjnegl8XlL/J ejjNlGUOW3Jt/69PJrjtc3HW/dU3QIHkM+miYv3YTn14N6PDPr9KNqLEUlxj58HEU5Oq 14N37VwDaqJAYn2ccfZukHBEeLusEg4hbBzab0tloJ4KbfgAtthoRO3aWwnqWWUM6aSz iVlht/dK9XO/ZnSVrvwRjMTRn77KHR9CQvauHW9fz9O/BG2tI+/G+hesfwrFDTmhhsbu H9YQ==
MIME-Version: 1.0
X-Received: by 10.170.89.130 with SMTP id g124mr37131909yka.24.1418867362012; Wed, 17 Dec 2014 17:49:22 -0800 (PST)
Received: by 10.170.195.21 with HTTP; Wed, 17 Dec 2014 17:49:21 -0800 (PST)
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D020E2116D1D@SC-VEXCH2.marvell.com>
References: <BF9DADF6-003F-454D-8E96-4A28A060CA72@isode.com> <A635D82B-B55C-4574-AB73-D0408853D642@gmail.com> <548ECB98.7060709@cs.tcd.ie> <7BAC95F5A7E67643AAFB2C31BEE662D020E2116D1D@SC-VEXCH2.marvell.com>
Date: Wed, 17 Dec 2014 17:49:21 -0800
Message-ID: <CACsn0ckh4C2rjhOD+RLASGoNwgSo+uX8-z2_=3rUhKsCxYFB7A@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BqeJQatpBvzbbP6VwEC9DSCNLKU
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Dec 2014 01:49:25 -0000
On Dec 17, 2014 3:17 PM, "Paul Lambert" <paul@marvell.com> wrote: > > > ] > ]On 15/12/14 11:16, Yoav Nir wrote: > ]> But I would really like to know who needs a PAKE right now. PAKEs > ]> require the server to store the cleartext password or a password > ]> equivalent, creating a security issue that is potentially worse than > ]> sending cleartext passwords through authenticated channels (as in > ]> form-based or basic authentication to a TLS-protected server) > ] > ]+many - PAKEs are IMO cool but mostly-useless crypto for exactly > ]this reason (and before others disagree, yes, I know some folks > ]disagree:-) If however, CFRG folk want to work on 'em I've no objection > ]but just so you all know, there is no horde of IETFers waiting with > ]bated breath for more PAKE protocol options. > > Yes there is ... The Wi-Fi industry needs a stable, open and broadly published version of the SAE protocol. Approval of the previously discussed draft-irtf-cfrg-dragonfly-05 would meet this need. Yes, it's not favored by some for the perceptions associated with the difficulty of construction of mathematically proof's for the protocols. Yes, Dragonfly is on a track to get wired into products and it would be very nice to have an open, concise and free (versus IEEE 802) specification of this one type of PAKE. I don't want to open up a dead horse, but: Why can't the Wifi alliance publish it's own spec? Anyone implementing Wifi has to pay for specs for the rest: not clear to me why this is that special, or why we are the goto group for publishing this. This doesn't seem to be a relevant consideration for us, since we deal with IETF protocols. Furthermore, draft-irtf-cfrg-dragonfly-05 went through last call a few months ago: it's no longer an issue, and I don't see why this draft has anything to do with that draft. > > While more stylish and acceptable by mathematicians, I see little value in SPAKE2. In this context I agree with your comment. There is not a good reason to create new applications of PAKE. There are better systems solutions where effort would be better spent. So, we're going to get rid of passwords in five years for the nth time? The effort of publishing does nothing to solve problems: implementing does. But when the only PAKE that works over ECC that is standardized/in an RFC, isn't very well understood, implementors will reach for it instead of potentially more analysed schemes. Insofar as we need a PAKE, it would be a good idea to get one in which we have confidence in the security. It's true that PAKEs have seen limited adoption compared to plain passwords, but there are many applications outside of the realm of IETF protocols that have used them. Furthermore, there is an augmented variant Dan Boneh calls PAKE2+. I am going to track it down, and it will partially resolve the issue of servers storing password equivalents. Currently there is no good reference for it. Sincerely, Watson Ladd > > > Paul > > ] > ]There are to be fair a quite small number of sensible people who do > ]figure there's a niche there to fill though (Dan H. for example but not > ]sure who else), so I could of course be wrong about that. > ]As I understand it, the niche Dan has in mind is for signing up to get a > ]certificate in a PKI, where the password is used to authenticate the > ]certificate request. Even in that case, I'm not convinced that PAKEs add > ]value - esp since a one (or limited) time use password could be better > ]there and requires no new crypto. > ] > ]It's also fair to say that the IETF hasn't ever done any kind of generic > ]consensus call on the (lack of) value of PAKEs, and the IETF does have a > ]history of adding PAKE options to protocols, (for some to me > ]unfathomable reason:-) so the above is just my personal opinion. > ] > ]S. > ] > ]_______________________________________________ > ]Cfrg mailing list > ]Cfrg@irtf.org > ]http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
- [Cfrg] Adoption of draft-ladd-spake2 as a RG docu… Alexey Melnikov
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Rene Struik
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Watson Ladd
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Watson Ladd
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … David Leon Gil
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Yoav Nir
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Stephen Farrell
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Michael Hamburg
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Dan Harkins
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Watson Ladd
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Dan Harkins
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Derek Atkins
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Dan Harkins
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Andy Lutomirski
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Paul Lambert
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Watson Ladd
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Dan Harkins
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Paul Lambert
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Tom Yu
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Andy Lutomirski
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Dearlove, Christopher (UK)
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Adam Langley
- Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG … Paul Lambert
- [Cfrg] On the topic of the SPAKE2 draft Paul Lambert
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Salz, Rich
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … D. J. Bernstein
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Mike Hamburg
- Re: [Cfrg] Point format endian (was: Adoption of … Salz, Rich
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Andrey Jivsov
- Re: [Cfrg] Point format endian Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Salz, Rich
- Re: [Cfrg] Point format endian (was: Adoption of … Damien Miller
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Mike Hamburg
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Yoav Nir
- Re: [Cfrg] Point format endian Michael Clark