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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2014 18:53:46 +0100

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.

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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 8 Oct 2014 11:09:43 -0700

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

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.

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
> 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
>   http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html

Why doesn't this apply to dragonfly, but only other proposals?

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).
>
> Best Regards,
> Alexey,
> on behalf of chairs.
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Oct 2014 15:26:18 -0700

On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <[email-masked]<mailto:[email-masked]>> 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.

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<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCAQFjAA&url=https%3A%2F%2Feprint.iacr.org%2F2013%2F058.pdf&ei=HLc1VK69L5KB8gXei4FQ&usg=AFQjCNGO0pMgiUZfq18oBD8pcxGvD3Ifdg&sig2=yjbHLr-wsdEjK4scL3RObg&bvm=bv.76943099,d.dGc>
It was interested that the only issue mentioned was a small subgroup attack if the public key is not validated …. which it always should.

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.

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.

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:

> 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.
>
> [email-masked]<mailto:[email-masked]>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 8 Oct 2014 15:46:23 -0700

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

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

> … and IETF standards.  Bringing in other good or bad protocols into the
discussion is irrelevant to the decision at hand.
> 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’.
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
>> > 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).

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Oct 2014 15:51:09 -0700

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

Yes, the review provided by the cfrg process has been very useful.  The protocol has been improved.  Now that it has been through multiple revisions it should be published.

Paul

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

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.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 8 Oct 2014 16:40:45 -0700 (PDT)

Watson,

On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote:
> Also,

  This has nothing to do with RC4 and renegotiation (I assume you mean
in TLS).

> and other comments incorporated into the draft.

  And I thanked Rene, you, and others for your comments and, as you note,
incorporated resolutions into the draft. Once again, thank you for helping
improve the draft. All of the comments have been resolved in -04.

  (I will note that the reflection attack you mentioned is not possible
in the IEEE 802.11 version of dragonfly, which predated your comment
and this draft by a few years, and neither was small subgroup attack
described by Clarke and Hao mentioned above. The -00 version of this
draft was rushed, take a look at the Acknowledgements in section 4 to
see just how bad, and I left some things out that I shouldn't have. All
this has all been addressed in -04).

> advance these is inexplicable.

  Oh no, it's very easily explained. It's because no one has stepped forward
to actually write the I-Ds. You have stated on numerous occasions that these
should be written up but you have never actually taken on the task of
actually doing it. Please, write up a draft or four.  Whether or not you do,
though, this really has nothing to do with the RGLC underway right now.

  If there was a security proof of dragonfly it would not be, nor should it
be, part of this draft. It would be a stand-alone paper. The complaint about
the lack of a security proof is really procedural and not technical as it is
not a comment on the draft that can be resolved by changing the draft.
The IRTF (and the IETF as well) has never put a security proof as a process
requirement for advancement of I-Ds. You may think it should but that
is an argument for a different place, not a RGLC.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 8 Oct 2014 18:22:29 -0700

>   This has nothing to do with RC4 and renegotiation (I assume you mean

I'm questioning the ability of market participants to evaluate cryptography.

> this has all been addressed in -04).

Why did the draft not track the IEEE 802.11 version? Also, as I
remember from discussing this issue in the TLS WG, the CFRG draft
version and the TLS draft version differed substantially, enough to
make the reflection attack not work. (There were interactions with the
rest of TLS that prevented it) While only tangentially relevant to the
issue, this is the kind of issue which leads to all sorts of bugs in
protocols that should be secure.

It also is not clear how relevant the proposed draft will be

> though, this really has nothing to do with the RGLC underway right now.

JPAKE was described in a series of drafts that weren't made WG work
items. I see no reason that the eventual disposition of SPAKE2, SMP,
or EKE+Elligator drafts would be any different, and thus see no reason
to write the drafts.

> is an argument for a different place, not a RGLC.

It could be resolved by opening the draft, deleting the contents,
inserting contents describing a protocol with a security proof and
referring to the proof published elsewhere, and submitting the new
version, so clearly it is an issue with the contents of the draft.

I think what you meant to say is it couldn't be resolved without
substantially changing the protocol, which also isn't true: if the
shared secret was a hash of all the messages, and the peer-scalars
were removed, the result would be a secure PAKE with a security proof.
But unfortunately it would be a patented one.

There are plenty of drafts that have piled up in various nooks and
crannies that never get adopted as WG items, despite requests from
authors. I don't see why we need to publish this draft, and I don't
see why we need to publish a draft for a protocol inferior to
alternatives that have been well-studied and are well-regarded. The
argument you are making seems to be that anything will get published,
provided it's sufficiently polished, no matter how much better the
alternatives are.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 8 Oct 2014 23:11:32 -0700 (PDT)

Watson,

> I'm questioning the ability of market participants to evaluate

  Well then you are making very odd comments. Market participants had
nothing to do with defining renegotiation. But, again, this has nothing to
do with the draft in question.

> protocols that should be secure.

  The draft was intended to be a generic instantiation of a key
exchange that had been defined in 3 different protocols, each of
which has its own idiosyncrasies. I dealt with the reflection issue in
the IEEE 802.11 instantiation because it was for mesh networks and
there is no notion of a "server" or a "client" or an "initiator" or a
"responder" in a mesh, everyone is an equal peer who can actually
each view themselves as the "initiator" if the timing is right. The
reflection attack was something that needed addressing in the
protocol as opposed to, say, the TLS variant which is not susceptible
to that attack due to the nature of TLS. Again, in my haste to generalize
the key exchange I removed stuff that should not have been removed.
But, as I mentioned, it is in the latest draft that is subject of the RGLC,
thanks to the useful and constructive comments of RG members,
including you.

>>>> “… Going to work on …” is the issue.  The draft under
>>>> discussion
>>>> has been

  The disposition is due to the diligence and hard work of the editor of
the I-D. If you want drafts to be produced in a RG (or WG) the best way
to do that is to socialize the idea, write the draft, and advocate for it.
If you sit back and send periodic emails criticizing everyone else for not
doing what you, in your wisdom from the comfort of your couch, see as
necessary nothing will get done.

> version, so clearly it is an issue with the contents of the draft.

  No, I'm talking about other protocols which have security proofs
behind the that have been specified in IRTF or IETF RFCs. Look at
SRP (RFC 2945). The security proof is not in the RFC. And if a security
proof of dragonfly comes around there is no reason why it should be
part of this I-D or a subsequent RFC.

> But unfortunately it would be a patented one.

  No, that's not what I mean at all. I mean that security proofs are
usually stand-alone papers (in the proceedings of the such-and-such
symposium of secure communications), not parts of RFCs. This is no
different.

> provided it's sufficiently polished, no matter how much better the

  If you have any further technical comments on the I-D, I encourage
their mention.

  regards,

  Dan.

---

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Thu, 9 Oct 2014 08:31:58 +0000

Hi,

>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

So why don't we start right now with a discussion on the requirements (independent from the current dragonfly draft)?

Some aspects I can think of right now: 

- Royalty-free use/Free of Patents
- Security (What kind of model are we considering)?
- Support various types of elliptic curves 
- Good performance, i.e. easy to implement,  number of exchanged messages (and sizes), computational costs

Further, I think we should keep the requirements for a mapping if the scheme is used with elliptic curves in mind:
- No mapping required
- Mapping on the curve (e.g. SWU, integrated Mapping)
- Uniform representation (e.g. Elligator, Elligator squared)

Finally, it might help to collect also use cases for PAKE protocols (A look at the "curves" list might also be useful, e.g. https://moderncrypto.org/mail-archive/curves/2014/000077.html).

What else do we need to consider? How should we prioritize the requirements?

Cheers,

Jörn

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Oct 2014 12:04:01 +0100

On 09/10/14 09:31, Schmidt, Jörn-Marc wrote:
>> suggested by our previous co-chair David McGrew
> So why don't we start right now with a discussion on the requirements
> (independent from the current dragonfly draft)?

I'll just note that there were also voices (incl. mine) saying:
"I really don't care about work on PAKEs. Seems like a waste of
time to me. But go ahead and spend time on that if you wish."

My own logic for that is that such work seems to me to be fine
cryptographic work, but of no use at all for IETF protocols. And
yes, I know there are some folks who disagree with that in general,
or who see specific niches cases where PAKEs might be useful. As
it happens, I don't, but like I say just that's a personal opinion
and not something with IETF consensus, so don't take my comment as
being "from the IETF" or similar.

For my money, I'd much prefer to see the additional curves discussion
reach a conclusion. And to the extent that work on PAKEs distracts
from that, which is hard to evaluate, I see working on PAKEs as a
slight negative.

S.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 9 Oct 2014 07:55:36 -0700

> do with the draft in question.

Did you read Peter's email? At some point we need to have a
substantive discussion of the security of dragonfly, because people
outside the CFRG don't have the training to do so. The fact that
dragonfly is hard to analyze is a negative not a positive.

> thanks to the useful and constructive comments of RG members,

Yes, it is now fixed. What else is wrong?
> necessary nothing will get done.

And Feng Hao wasn't working hard enough promoting JPAKE? Again, there
was significant development of various alternatives on the CFRG
mailing list, and if what you need is an RFC draft to consider an
alternative, that's easy to write.

I feel the issue is that you don't believe the CFRG actually analyzes
alternatives, merely edits drafts describing protocols, whereas I
think the CFRG analyses alternatives, and the actual draft writing is
trivial in comparison.

I'll happily write the drafts this weekend. But I doubt that any
degree of hard work will lead to adoption or publication.

> part of this I-D or a subsequent RFC.

But isn't the existence of the proof relevant, even if it's not in the
RFC? Furthermore, a security proof will not come around: I agree with
the original assessment that "this is not the kind of protocol we
prove secure". I've tried several times without success, and I don't
think I'm the only one trying.

>   If you have any further technical comments on the I-D, I encourage

How do I know we didn't make more mistakes?

---

From: Paul Lambert <[email-masked]>
Date: Thu, 9 Oct 2014 09:55:25 -0700

>time to me. But go ahead and spend time on that if you wish."

+1 mostly.

Shared passwords are architecturally problematic.  They are
more useable ways to authenticate.  As a community we should
be spending time on forward looking opportunities.

The Œmostly' is that the Dragonfly draft should be published
so it can be used a little better in a couple of specific
environments where it is already being wired into systems.
Specifically, IEEE 802.11 has the SAE protocol which uses
the Dragonfly exchange for mesh networks.  There are other
peer-to-peer wireless applications that could use Dragonfly
soon. In particular, the Wi-Fi industry also has a long
standing issue with password based authentication
being subject to brute-force attacks in the
WPA2=Personal authentication (aka 4-way handshake).
Dragonfly in the form of SAE will potentially
be dropped in as a replacement for the current
hash based exchange.

J-PAKE is also a Œnice¹ looking PAKE algorithm with a good
credentials. Someone should take the time to continue it¹s
documentation and progression Š but I would NOT want to be
using any PAKE directly in the future as a primary means of
authentication. A PAKE-like construct might be
incorporated as a building block in some non-password
based authentication system, but is not a pressing
industry need at this level of abstraction.

J-PAKE is NOT a viable near term replacement for
Dragonfly in the wireless market. It takes many
hundreds of hours of work and years of effort to
push real industry adoption of a technology in
markets that involve multiple interoperating
vendors. Applications, like Mozilla, can push
fast and wide adoption of mechanisms like J-PAKE
without having to deal with the sluggish nature
of broader interoperability forums (like Wi-Fi).

Dragonfly is in it¹s 8th trimester of birth. It¹s
been pointed out that while it appears to be completely
healthy, there is no Œproof¹ that it¹s genetic structure
can be proven to be Œhealthy¹. No unresolved flaws
have been identified. A vocal zealot from the Church
of Formal Reduction insists that it be aborted
because it has not been blessed.

This Œbaby¹ may not be as cute as others, but it has a
planned and ready forum for adoption.  Dragonfly should
be published.  This does not prevent other PAKE¹s from
emerging (which they should).  Publishing Dragonfly is
not a recommendation that it is the best PAKE,
or the long term answer for global warming.
Publishing Dragonfly provides a stable reference
versus a transient draft.  The cfrg review has helped
to create a clear and correct specification that should
be published.

>being "from the IETF" or similar.
Yes.  Standalone PAKEs are not good general solutions for
IETF protocols, but the nature of Œgood general solutions'
are not worth debating without the context of specific usage.

Starting new debate on new mechanisms is not relevant
to the discussion of the clarity and correctness of a proposed
RFC.  Dragonfly should be published.

>from that, which is hard to evaluate, I see working on PAKEs as a

Another reason to publish Dragonfly and move on. J-PAKE or
other PAKEs will be brought to this forum for review,
but involved development of requirements and comparisons
of Œbest¹ is a waste of this forums time.

Paul

PS - my apologies to the list for posting my opinion again
that Dragonfly be published as an RFC (oops did it again :-)
I will back away for awhile to hear other voices on the list.
Repetition of position does not help the consensus determination.

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 9 Oct 2014 10:21:00 -0700

> be dropped in as a replacement for the current

I believe that this is exactly why quite a few people (myself
included) think that CFRG should think long and hard before publishing
Dragonfly.  To the extent that CFRG's imprimatur will enourage
IEEE802.11 adoption of Dragonfly, CFRG should *not* bless Dragonfly.

Let's review:

IEEE802.11 adopted WEP despite best practices suggesting that the
protocol, as designed, should not be used.  As far as I know, no one
knew how to break it when it was adopted, but no one had a compelling
argument that it couldn't be broken.

WEP was later upgraded to WPA2 (I'm ignoring TKIP and friends).  There
was no security proof for WPA2, but it seemed good enough, especially
given the contraints at the time.  IIRC it ended up being considerably
weaker than hoped.

Now apparently Dragonfly is being proposed.  At least Dragonfly claims
to have the right security properties.  But, from reading all the
discussion here, it seems that Dragonfly is only unbroken because the
issues in early drafts were fixed and the known attempts to attack it
don't work.

But this is ridiculous for a new protocol.  There are multiple simple
protocols with security proofs, *especially* for balanced PAKEs.
There are the various SPAKE flavors, J-PAKE, and (my favorite because
it's so simple) DH-EKE.

If CFRG wants to publish the Dragonfly draft with a statement that
Dragonfly is not recommended for new designs, that's one thing.  But
publishing it as is, especially if that will be seen as a sign that it
is appropriate to use in new designs, seems dangerous.

--Andy

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 09 Oct 2014 10:39:15 -0700

Before this topic entirely fades away, for those of you who think PAKEs 
are worthwhile: what properties are useful in a PAKE?  Did Jorn-Marc 
Schmidt cover it?  Do you have extra requirements on message orders, 
augmentation, or anything like that?  I'm trying to configure 
SPAKE2+Elligator in a way that covers how people will actually want to 
use it.

Feel free to respond off-list, since at least Paul and Sephen think it's 
not worth discussing this on list.

-- Mike

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Oct 2014 18:40:18 +0100

Hi,

On 08/10/2014 19:09, Watson Ladd wrote:
>
> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <[email-masked] 
> <mailto:[email-masked]>> 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.
> >
> 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.
>
> 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.
>
> >

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.

> > 3) be constructive. In particular if you would like a disclaimer 
> being added to the document, please suggest specific text.
> 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).

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Oct 2014 18:58:05 +0100

Hi,

>>> On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins <[email-masked]> wrote:
  [snip]
> Yes, it is now fixed. What else is wrong?
This is not a reasonable question to ask. If we start asking questions 
like this we will never finish anything.
>>>>>>> security
I would advise to ask CFRG chairs first about whether they would 
consider acceptance of JPAKE as a RG document. So far the question 
hasn't been asked.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Oct 2014 19:05:09 +0100

[snip]

> to do that is to socialize the idea, write the draft, and advocate for it.
At least this co-chair agrees with this. Write a proposal and email 
chairs or ask chairs to adopt an existing draft.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Oct 2014 19:09:36 +0100

> So why don't we start right now with a discussion on the requirements (independent from the current dragonfly draft)?
I think discussing PAKE requirements in parallel is fine, although this 
CFRG co-chair was trying to channel limited RG energy to deal with one 
or two issue at a time :-).

---

From: Watson Ladd <[email-masked]>
Date: Thu, 9 Oct 2014 12:45:55 -0700

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

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.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Oct 2014 23:53:11 +0300

On Oct 9, 2014, at 7:55 PM, Paul Lambert <[email-masked]> wrote:

> more useable ways to authenticate.

I wish I had a dollar for every time someone said that in the last 20 years…

> the Dragonfly exchange for mesh networks.

That’s the part I don’t understand. Since the first revision of this document, the group made some suggestions for improvement that have been incorporated into the draft. 

We also have Dan’t message ([1]) describing differences between the 802.11 version and this draft, including attacks that work on earlier versions of this draft that don’t work on the 802.11 version.

Given all that, I don’t think this is a document that describes existing practice, in the same vein as an SSLv3 document or a PKCS#12 document. This is a document describing an entirely new PAKE, so it should be judged as such.

Yoav
[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg05210.html

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 9 Oct 2014 15:42:50 -0700 (PDT)

> I wish I had a dollar for every time someone said that in the last 20

  Me too.

  If I got a dollar every time authentication on the Internet involved
a password and I had to pay a dollar every time authentication on
the Internet did not, I would be a billionaire many times over.

> That’s the part I don’t understand. Since the first revision of this
> document, the group made some suggestions for improvement that have been
> incorporated into the draft.
>
> We also have Dan’t message ([1]) describing differences between the 802.11
> version and this draft, including attacks that work on earlier versions of
> this draft that don’t work on the 802.11 version.

  I think you misunderstood my email. This draft was supposed to be a
generic specification for the key exchange underlying an authentication
method in several other protocols. So the point of my mail was to explain
that the attacks mentioned on this list-- the small subgroup attack and
the reflection attack-- are not new, they were known and addressed in the
other specifications, but in my haste to get the I-D out (if you look at the
Acknowledgements section you'll see that it's actually the xml2rfc
boilerplate, it was that sloppy) I did not address them in the generic
protocol description.

  After these omissions were pointed out the appropriate checks were
added to subsequent versions of this draft.

> Given all that, I don’t think this is a document that describes existing
> practice, in the same vein as an SSLv3 document or a PKCS#12 document.
> This is a document describing an entirely new PAKE, so it should be judged
> as such.

  Actually, it now closer to existing practice. It is a generic description
of which there are other specific instantiations of it. There were no
comment resolutions that changed the underlying protocol and to say
it is an "entirely new PAKE" is just wrong.

  regards,

  Dan.