Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 15 December 2014 11:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 61F291A1B34 for <cfrg@ietfa.amsl.com>; Mon, 15 Dec 2014 03:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 9LPmYt7LZA58 for <cfrg@ietfa.amsl.com>; Mon, 15 Dec 2014 03:52:57 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE461A1B20 for <cfrg@irtf.org>; Mon, 15 Dec 2014 03:52:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B507BE13; Mon, 15 Dec 2014 11:52:56 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDzSA9-2fwax; Mon, 15 Dec 2014 11:52:56 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 30348BE0B; Mon, 15 Dec 2014 11:52:56 +0000 (GMT)
Message-ID: <548ECB98.7060709@cs.tcd.ie>
Date: Mon, 15 Dec 2014 11:52:56 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>
References: <BF9DADF6-003F-454D-8E96-4A28A060CA72@isode.com> <A635D82B-B55C-4574-AB73-D0408853D642@gmail.com>
In-Reply-To: <A635D82B-B55C-4574-AB73-D0408853D642@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/y7_guOMvOi2Gqk_8vlPAUIoah-8
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: Mon, 15 Dec 2014 11:52:59 -0000


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.

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.