Re: [Cfrg] Dragonfly has advantages

Feng Hao <feng.hao@newcastle.ac.uk> Mon, 06 January 2014 17:46 UTC

Return-Path: <feng.hao@newcastle.ac.uk>
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 613DC1AE136 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 09:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 7lCI377AW5SO for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 09:46:04 -0800 (PST)
Received: from cheviot12.ncl.ac.uk (cheviot12.ncl.ac.uk [128.240.234.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8671D1AE12E for <cfrg@irtf.org>; Mon, 6 Jan 2014 09:46:04 -0800 (PST)
Received: from exhubvm03.ncl.ac.uk ([128.240.234.7] helo=EXHUBVM03.campus.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from <feng.hao@newcastle.ac.uk>) id 1W0EFP-0006hk-CA; Mon, 06 Jan 2014 17:45:55 +0000
Received: from EXMBDB02.campus.ncl.ac.uk ([fe80::c039:e17:9d60:9f3]) by EXHUBVM03.campus.ncl.ac.uk ([fe80::517e:5471:8227:7937%10]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 17:45:45 +0000
From: Feng Hao <feng.hao@newcastle.ac.uk>
To: Paul Lambert <paul@marvell.com>
Thread-Topic: [Cfrg] Dragonfly has advantages
Thread-Index: AQHPCnLdZWZqHtlLtUCc2iothWRdhpp3qe6AgABKTgCAAAUbAA==
Date: Mon, 06 Jan 2014 17:45:44 +0000
Message-ID: <CEF0998C.22E20%feng.hao@newcastle.ac.uk>
In-Reply-To: <CEF025DF.2B941%paul@marvell.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [10.4.160.7]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <81A4DC3A28BE7149BBC91453D57CC3E6@fangorn.ncl.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:46:07 -0000

Hi Paul,

On 06/01/2014 17:27, "Paul Lambert" <paul@marvell.com> wrote:

>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


Agreed. What you recommend is also in line with what David suggested
earlier.

I've been liking the openness of the CFRG forum and the diversity of
backgrounds that its participants are from. I feel it is in a unique
position to bridge that disconnect.

Feng


>
>
>
>>
>>>
>>>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
>>>
>>
>