[Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 09 October 2014 11:04 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 628151ACD45 for <cfrg@ietfa.amsl.com>; Thu, 9 Oct 2014 04:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.386
X-Spam-Level:
X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 K0IVQmgsKQhb for <cfrg@ietfa.amsl.com>; Thu, 9 Oct 2014 04:04:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E199B1A0275 for <cfrg@irtf.org>; Thu, 9 Oct 2014 04:04:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01D19BDF8; Thu, 9 Oct 2014 12:04:06 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 vrUSxlm0gffW; Thu, 9 Oct 2014 12:04:04 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.42.22.80]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D638BDCF; Thu, 9 Oct 2014 12:04:04 +0100 (IST)
Message-ID: <54366BA1.1010603@cs.tcd.ie>
Date: Thu, 09 Oct 2014 12:04:01 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: "\"Schmidt, Jörn-Marc\"" <Joern-Marc.Schmidt@secunet.com>, Alexey Melnikov <alexey.melnikov@isode.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de>
In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SW5sNtAsFjos8n0BPBK2DDMjtPI
Subject: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status)
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, 09 Oct 2014 11:04:08 -0000


On 09/10/14 09:31, Schmidt, Jörn-Marc wrote:
>> 1) keep in mind that CFRG chairs believe that the RG should work on
>> PAKE requirements and after that on other PAKE proposals. This was
>> suggested by our previous co-chair David McGrew
>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html
>
> So why don't we start right now with a discussion on the requirements
> (independent from the current dragonfly draft)?

I'll just note that there were also voices (incl. mine) saying:
"I really don't care about work on PAKEs. Seems like a waste of
time to me. But go ahead and spend time on that if you wish."

My own logic for that is that such work seems to me to be fine
cryptographic work, but of no use at all for IETF protocols. And
yes, I know there are some folks who disagree with that in general,
or who see specific niches cases where PAKEs might be useful. As
it happens, I don't, but like I say just that's a personal opinion
and not something with IETF consensus, so don't take my comment as
being "from the IETF" or similar.

For my money, I'd much prefer to see the additional curves discussion
reach a conclusion. And to the extent that work on PAKEs distracts
from that, which is hard to evaluate, I see working on PAKEs as a
slight negative.

S.