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

[Watson Ladd <[e-mail]>]

On Oct 9, 2014 10:40 AM, "Alexey Melnikov" <[e-mail]>
wrote:
>
> Hi,
>
>
> On 08/10/2014 19:09, Watson Ladd 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.
>>
>> My comment (there is no security proof, and alternatives with better
provable security) has been acknowledged to be unresolveable. The draft
authors knew this from the very beginning.
>
> Ok, your opinion was heard.
>
>> 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.
>
> Chairs can't promise that the RG will ever converge on requirements. We
can try, but there is no guaranty that anything will come out of this later
effort.
>
>> There is plenty of terrible crypto in IEEE standards we don't issue
drafts for because it is so terrible. 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?
>
>
> Because Dragonfly got there first. I don't think it is reasonable to
delay the document which is effectively done and not known to be broken.

And this doesn't apply to Curve 25519 because? Regardless of the eventual
decision on either one, it's surprising we consider alternatives for one
but not the other.

It's clear dragonfly will be published from what you are saying. But what I
can't figure out is why.

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