Re: [Cfrg] draft-irtf-cfrg-dragonfly document status

[Watson Ladd <[e-mail]>]

On Oct 8, 2014 3:26 PM, "Paul Lambert" <[e-mail]> wrote:
>
>
>>
>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <[e-mail]>
wrote:
>> >
>> > Hi,
>> > My apologies for taking so long on this. But I felt I needed to review
mailing list discussions to make up my own mind on this topic.
>> >
>> > After reviewing mailing list discussions about this draft, I would
like to do another RGLC on it. I've seen negative comments on the mailing
list, but I've also seen some interest in this work and I am also aware
that some variants of the algorithm are already implemented/deployed. Also,
there were a couple of new revisions of the draft and it is not clear
whether people who reported original problems are happy with how they got
resolved. So I would like to see a bit more positive feedback on the latest
version, in particular I would like to know if specific issues raised by
earlier reviews are addressed in the latest version.
>
> This draft should be published as an RFC.  There is considerable value in
having a published stable reference document.   The market should be
allowed to do the estimations of risk and value to field this protocol.

Just as they did with RC4 and renegotiation?

>
> Versions of the protocol have been adopted and fied. This protocol was
first  introduced into IEEE 802.11s in 2008. The base protocol exchange has
also been adopted in the Wi-Fi  Alliance.  The protocol has been improved
by the review in the cfrg and if published, the specification would
positively impact the application of the protocol in other forums.
>
>> My comment (there is no security proof, and alternatives with better
provable security) has been acknowledged to be unresolveable.
>
> Yes, this may be considered a negative point by some but not all.   While
not a proof, the protocol has been analyzed:
> Cryptanalysis of the Dragonfly Key Exchange Protocol
> It was interested that the only issue mentioned was a small subgroup
attack if the public key is not validated …. which it always should.

This analysis ignores Rene Struik's timing attack, my reflection attack,
and other comments incorporated into the draft.

>>
>> The draft authors knew this from the very beginning.
>>
>> I don't think we should approve a protocol that doesn't have a security
proof, particularly given that we are going to work on alternatives.
>
> “… Going to work on …” is the issue.  The draft under discussion has been
on IETF servers for 2 years.  It has been used in other industry forums for
four or five years.

Plenty of alternatives have been put forward in those two years, including
EKE+Elligator,  SPAKE2,  JPAKE,  and SMP based solutions. The failure to
advance these is inexplicable.

>
> Yes, the cfrg should work as quickly as possible to make alternatives.
Stopping the progression of this draft does not accelerate new work, but
does prevent existing applications from utilizing a reviewed and improved
specification.

The nonexistence of this draft did not stop adoption in Wifi. By contrast
advancing a number of PAKEs will kick the issue to WGs without the capacity
to evaluate the issues.

>>
>> There is plenty of terrible crypto in IEEE standards
>
> … and IETF standards.  Bringing in other good or bad protocols into the
discussion is irrelevant to the decision at hand.
>>
>> we don't issue drafts for because it is so terrible.
>
> Since when did the IETF mandate a security proof …   There are terrible
protocols with proofs, so why does the lack of a proof made something
‘terrible’.
>
> Paul
>
>
>
>> To the extent our publication leads to use of dragonfly as opposed to
known - good protocols, it's a problem.
>
>
>
>
>> >
>> > Considering how difficult previous Last Call on the document was, I
would like to ask people to:
>> > 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
>>
>> Why doesn't this apply to dragonfly, but only other proposals?
>>
>> > 2) be professional, in particular no ad hominem attacks
>> > 3) be constructive. In particular if you would like a disclaimer being
added to the document, please suggest specific text.
>> > 4) simple statements of support for publishing the document or
objection to publishing it are fine and encouraged. Sending them directly
to RG chairs is fine. But please avoid saying "but what about PAKEXXX?",
due to 1).
>> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus.
However I would like to see us try.
>> >
>> > Best Regards,
>> > Alexey,
>> > on behalf of chairs.
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> > [e-mail]
>> > http://www.irtf.org/mailman/listinfo/cfrg
>
>