Re: [Cfrg] dragonfly, was: Re: Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts

[Björn Haase <[e-mail]>]

As a cryptographer working on PAKE, I am somewhat astonished to learn
that IETF might seriously considering to consider a construction like
dragonfly for standardization.

There are several defiencies in Dragonfly in my assessment.

1.) The fact that a "Hunting and Pecking" method is prescribed for
generating secret common group element is -- in my opinion -- the major
security and efficiency problem.

Note that its not a problem to deal with in a security proof because
this is a pure implementation pitfall issue because it makes
implementers very tempted to choose insecure "speedups". Saying this,
after having experience with rolling out security solutions in teams
without crypto and security experience, I am convinced that this major
implementation vulnerabilities *would* be showing up in real-world
settings. Specifically on resource-constrained targets.

Seeing that SPEKE and EKE patents have expired recently and seeing that
decent and carefully analyzed alternatives such as the SPAKE
constructions PACE and it's derivatives or TBPEKE (the balanced version
of VTBPEKE) are available I personally am astonished to see that
nowadays somebody might actually consider to newly standardize any
protocol requiring "Hunting and Pecking"!

2.) Another point is the requirement completely ruling out
state-of-the-art high-speed Edwards curves (co factor must be 1 for
dragonfly). In my opinion this again comes with the risk of adding
implementation pitfalls. Implementations focusing on DJB's Curve25519 or
Mike Hamburg's 448 would have to add and maintain/patch
short-weierstrass algorithm families.


In my opinion there are by far better and more inter-operable choices
available than dragonfly for balanced PAKE, especially SPAKE and
SPEKE-derivates (such as PACE and CPace) which are more secure in
real-world settings (considering the risk of implementation pitfalls and
non-constant run-times).

Were the points I mentioned above regarding problems with dragonfly
considered beforehand on this list? I would believe that these points
are so obvious that getting consensus on these aspects among
implemention-oriented cryptographers would be easy to establish.

Yours,

Björn


Am 27.03.2019 um 17:37 schrieb Tony Arcieri:
> There is, if nothing else, some confusion around the IETF's
> relationship to Dragonfly, both within the WiFi Alliance and by tech
> journalists. Some examples:
>
> https://mailarchive.ietf.org/arch/msg/cfrg/lNFkQxnCQpi7dEX6cNI0ewZAuGw
>
>     Also note individual submission:
>     https://tools.ietf..org/html/draft-harkins-salted-eap-pwd-02
>     <https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-02>EMU
>     and Security Area review incorporated, IETF Last Call pending..
>     Related draft (will be RFC 7664), see
>     https://datatracker.ietf.org/doc/draft-irtf-cfrg-dragonfly/.
>
>
> https://www.darkreading.com/operations/wpa3-brings-new-authentication-and-encryption-to-wi-fi/d/d-id/1332145
>
>     WPA3 Personal authentication is a process called a simultaneous
>     authentication of equals (SAE), which comes from the *IETF
>     Dragonfly* <https://tools.ietf.org/html/rfc7664> key exchange.
>     Robinson says that with SAE, the authentication requires
>     interaction, and only after authentication will the keys be
>     generated. This makes attacks that depend on cloud-based server
>     farms and automated key attempts unavailable to attackers.
>
>
> https://www.eweek.com/security/next-generation-wpa3-wifi-security-standard-launches
>
>     "SAE uses a Dragonfly handshake defined in the Internet
>     Engineering Task Force (IETF) RFC 7664 specification and applies
>     it to a WiFi network for password-based authentication," Robinson
>     explained. "The Wi-Fi Alliance WPA3 specification defines
>     additional requirements for devices operating in SAE modes."
>
>
> From what I've observed, the IETF's name seems to end up attached to
> Dragonfly quite a bit. Curiously in these quotes, the CFRG and IRTF
> aren't mentioned at all. Perhaps this speaks to a more general problem
> around public perception of RGs and informational RFCs (or lack
> thereof), but when I read quotes like this, they sound to me like many
> people's perception is that Dragonfly is a standards-track IETF RFC.
>
> Issues like educating the tech press and trade associations on the
> difference between the IETF and IRTF and the difference between
> standards-track and informational RFCs aside, I think the main thing
> the IETF could do address these concerns is actually create a WG
> dedicated to producing a standards-track PAKE for similar use cases.
> PAKEs are certainly a hot topic these days, both on the CFRG (see
> OPAQUE thread this morning) and in cryptography in general.
>
> --
> Tony Arcieri
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg