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

Paul Lambert <paul@marvell.com> Tue, 06 January 2015 18:30 UTC

Return-Path: <paul@marvell.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 18AEE1A1B18 for <cfrg@ietfa.amsl.com>; Tue, 6 Jan 2015 10:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 kKMnbL0lb2Qi for <cfrg@ietfa.amsl.com>; Tue, 6 Jan 2015 10:30:53 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427CE1A0016 for <cfrg@irtf.org>; Tue, 6 Jan 2015 10:30:53 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t06IUCQR010317; Tue, 6 Jan 2015 10:30:52 -0800
Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1rqrtjmqe7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jan 2015 10:30:52 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([::1]) with mapi; Tue, 6 Jan 2015 10:30:50 -0800
From: Paul Lambert <paul@marvell.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Tue, 6 Jan 2015 10:30:48 -0800
Thread-Topic: [Cfrg] Adoption of draft-ladd-spake2 as a RG document
Thread-Index: AdAp3uTq+UpIuphXTi+AubHg9QIYtQ==
Message-ID: <D0D165D8.5757E%paul@marvell.com>
References: <BF9DADF6-003F-454D-8E96-4A28A060CA72@isode.com>
In-Reply-To: <BF9DADF6-003F-454D-8E96-4A28A060CA72@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D0D165D85757Epaulmarvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_07:2015-01-06,2015-01-06,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501060183
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_ccbgBOU1kKWdSKMjihnlU3LsEw
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: Tue, 06 Jan 2015 18:30:55 -0000



Hi,
This message starts 3 weeks adoption call for draft-ladd-spake2. Please reply to this message or directly to CFRG chairs, stating one of the following

1) that you are happy to adopt the draft as a starting point
Starting point for what?  A definition of SPAKE2, or can we step back briefly and discuss requirements?
A PAKE is a building block … but not one with attributes that I’d recommend except for some very narrow use cases.

2) that you are not happy to adopt this draft
It might be a starting point for a PAKE, but is incomplete.  So, no.  However, it is worth discussing and improving if the goal is to provide a stable reference for SPAKE2.

3) that you think the document needs more work before the RG should consider adopting it
Yes. It’s missing:
 -  M and N definitions missing
 - Use of names and addresses in the calculation needs some work or rethink … again, what are requirements and what are we authenticating.
 - test vectors and wire formats
 - would be better if made into a more symmetric protocol and had a state machine definition


While detailed document reviews are generally welcome, this not a call to provide detailed comments on the document.
SPAKE2 has been used in industry.  Is the goal to document current practice?  That would lead to one set of comments.

Are we working to define a generally useful security protocol exchange with specific properties? That would be a different set of comments and perhaps more useful for long term impact.  I’d rather see energy spend on this topic than perpetuate PAKE based solutions, but this need not be mutually exclusive to defining SPAKE2.

Paul



Alexey,
On bahalf of CFRG chairs.