Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt

[Paul Lambert <[e-mail]>]

>From: Cfrg [mailto:[e-mail]] On Behalf Of Watson Ladd
>Sent: Monday, February 03, 2014 2:11 PM

>Sure: "Despite significant efforts, no variant of this protocol has been proved
>secure even in the random oracle model with nonstandard assumptions.

A proof might be desirable but should not block the use of a proposed protocol.
For example there is no adequate proof that integer factorization is “secure”.
This is not a reason to stop using RSA based algorithms.  The lack of
a  complete security proof for draft-irtf-cfrg-dragonfly-03.txt should not
stop it’s use (in fact it’s already in other standards that would benefit
from the analysis and improvements of this group).

I would like to reverse the question.

Watson, in your technical analysis of the
protocol in its current form (draft-irtf-cfrg-dragonfly-03.txt),
can you identify any exploitable security flaw specific to
the protocol?



Paul


From: Cfrg [mailto:[e-mail]] On Behalf Of Watson Ladd
Sent: Monday, February 03, 2014 2:11 PM
To: David McGrew
Cc: [e-mail]
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt


On Feb 3, 2014 1:49 PM, "David McGrew" <[e-mail]<mailto:[e-mail]>> wrote:
>
> On 02/03/2014 02:47 PM, Watson Ladd wrote:
>>
>>
>> On Feb 3, 2014 11:27 AM, "Dan Harkins" <[e-mail]<mailto:[e-mail]>> wrote:
>> >
>> >
>> >   Hello,
>> >
>> >   I updated the dragonfly draft to incorporate the comments received
>> > from Rene and Scott. Please take a look.
>> >
>>
>> It still doesn't compare favorably to JPAKE or SPAKE2. TLS has shown less then zero interest in it. No reduction or evidence for claims made is forthcoming. The draft excludes curves with uniform hashing to points.
>>
>> Why is this specific PAKE a work item and not the other alternatives?
>
>
> You mean like draft-irtf-cfrg-augpake-00?
>
> Drafts are taken up when someone is willing to write one, and there are sufficiently many other people that are interested.
>
>> Was this a joke for groundhog day?
>
>
> The sarcasm is not helpful.  Let's stick to a technical discussion.
>
> This draft most certainly should be reviewed, since security concerns were raised regarding earlier versions of the draft, especially regarding implementation guidance and timing channels.
>
> The process by which CFRG drafts can become RFCs is described in http://wiki.tools.ietf.org/html/rfc5743#section-2.1   Note that there is a paragraph in the RFC that describes the relationship of that work to the research group.    This mechanism enables the sentiment of the RG to be captured in the RFC.
>
> Let me ask: can you suggest text for the security considerations section of this draft that captures your concerns regarding the lack of reduction and uniform hashing?

Sure: "Despite significant efforts, no variant of this protocol has been proved secure even in the random oracle model with nonstandard assumptions. None of the security claims are sensible in any accepted formalization of security protocols. Significant dissent in the WG existed with publication due to the lack of any more than superficial analysis. No Internet protocol should use this PAKE when alternatives exist." Just about sums it up.
>
> David