On 10/9/14, 4:04 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

>
>
>On 09/10/14 09:31, Schmidt, Jörn-Marc wrote:
>>> 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
>>
>> 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."

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



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



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

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.



>
>S.
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg