Re: [Cfrg] Dragonfly has advantages

Paul Lambert <paul@marvell.com> Mon, 06 January 2014 17:27 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 DBE0D1AE12C for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 09:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
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 sJYRklZ8Z3pw for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 09:27:35 -0800 (PST)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6C81E1AE12A for <cfrg@irtf.org>; Mon, 6 Jan 2014 09:27:35 -0800 (PST)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s06HR0lK009763; Mon, 6 Jan 2014 09:27:27 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1h5qbud9r3-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 06 Jan 2014 09:27:26 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 6 Jan 2014 09:27:26 -0800
From: Paul Lambert <paul@marvell.com>
To: Feng Hao <feng.hao@newcastle.ac.uk>
Date: Mon, 6 Jan 2014 09:27:26 -0800
Thread-Topic: [Cfrg] Dragonfly has advantages
Thread-Index: Ac8LBJGP2QTkqUXvTe+MBn/2fakEmw==
Message-ID: <CEF025DF.2B941%paul@marvell.com>
References: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6DEBA@SC-VEXCH2.marvell.com> <CEF051D6.22D91%feng.hao@newcastle.ac.uk>
In-Reply-To: <CEF051D6.22D91%feng.hao@newcastle.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-06_02:2014-01-06, 2014-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-1305240000 definitions=main-1401060101
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Dragonfly has advantages
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, 06 Jan 2014 17:27:37 -0000

Hi Feng,

Thank you for the discussion.

>>> -----Original Message-----
>>> From: Feng Hao [mailto:feng.hao@newcastle.ac.uk]
>> 
>>
>>Hi Feng,
>>
>>> >I agree that it has more complexity and message exchanges that other
>>> >approaches.  These other protocols have NOT been viable to ship in the
>>> >products I build.
>>> 
>>> Have you looked at J-PAKE? It's a balanced PAKE, same as Dragonfly.
>>No, not in too much detail, yet ... looks of similar complexity.
>
>
>Well, if you look into the protocol and the proofs, you may realize that
>J-PAKE is designed for "simplicity" rather than "complexity".
>
>It is my belief that keeping things simple (which should include the
>protocol specification, security proofs and implementation) should be the
>the most important consideration in the design of security protocols. Some
>people may not realize it, but the hardest task in designing a security
>protocol is actually to "keep it as simple as possible".
> 
>
>>> 
>>> http://www.lightbluetouchpaper.org/2008/05/29/j-pake/	
>>Interesting, thanks for the reference.
>>
>>I assume this is a related better spec for this forum:
>>http://tools.ietf.org/search/draft-hao-jpake-00
>
>Yes. Also note that the protocol has remained unchanged from its initial
>publication in 2008.

There seems to be an ongoing disconnect between academic analysis, RFC
publications and real-world applications.

Perhaps clarity in the documentation of use cases, analysis, comparisons
and recommendations is something we can work on within this community.

Paul



>
>>
>>Seems like the identical problem space as Dragonfly, but a later attempt.
>>Less critical review so far ...
>
>
>Not sure if it's a later attempt, but J-PAKE was first published in 2008.
>It may not be obvious to some, but the protocol has actually been
>extensively analyzed by researchers in the security community and the
>industry in the past 5 years. We patiently waited for 5 years to give the
>public ample time to scrutinise the protocol and the proofs, and so far no
>attacks has been found.
>
>But as always, I welcome most critical reviews from people on this list.
>Feel free to post your comments on the lightbluetouchpaper blog, which is
>open to everyone to comment.
>
>>
>>Note - a nearly identical version of Dragonfly	 is baked into mesh
>>networking ... so I still want to see Dragonfly progress to ensure the
>>side-channel implementation details and the like are clarified to fully
>>address the comments.
>
>Of course. I think a prototype implementation of Dragonfly (in c or Java
>etc) would help clarify a lot of things.
>
>>
>>Regards,
>>
>>Paul
>>
>>> 
>>> In the update of "2013-12-30", you can find a prototype implementation
>>> of J-PAKE using the elliptic curve group setting.
>>> 
>>> Cheers,
>>> Feng
>>
>