PAKEs ("password authenticated key exchanges") are a kind of public-key algorithm.
When two people use public key crypto to exchange a key in public, they need a way to "break the tie" in case of a MITM attacker. The conventional way to do this is with a certificate; that's how TLS works.
A PAKE uses instead a password; it does that by baking the password into the public/ephemeral key generation process. Alice & Bob can't agree on a MITM'd key if the MITM doesn't know the password; they just won't come up with the same numbers.
Dragonfly is a PAKE designed by Dan Harkins a bunch of years ago. Harkins got Dragonfly added to LEAP, the extensible authentication framework for 802.11 networks. He would very much like it added to TLS as well.
The trouble with that is, nobody knows why we would want to add Dragonfly to TLS. TLS already has a PAKE option, SRP. SRP is better than Dragonfly; it's designed to make it hard for an attacker who seizes a server to collect a database of passwords. SRP is also well-studied and well-understood; if it isn't particularly beloved of academic cryptographers, well, Dragonfly doesn't score any better. But more importantly, nobody uses TLS-SRP. No browser implements it. The demand for PAKE authentication in TLS is not strong.
It gets worse for Dragonfly. The protocol has problems. I'm going to get myself into a little bit of trouble summarizing, but here goes: Dragonfly can be made to work with elliptic curve key exchange. The process for mixing a password into an ECC key exchange involves a trial-and-error process for finding a valid curve point; a loop runs conducting these trials. A passive attacker could, in an earlier version of the Dragonfly protocol, discern how many iterations through the loop had happened to find a valid point given a password. Dragonfly is randomized: a nonce is mixed into every exchange. As a result, the same password might take a different number of loop iterations on every login attempt.
Net result: given a corpus of 232 passwords, 32-and-change passive observations of the key exchange might uniquely identify the password used!
Modifications to the protocol were proposed, some in the CFRG process, but they in turn resulted in a protocol with a side-channel weakness: the process of computing parameters for the key exchange leaks timing information.
Dragonfly has one sponsor that we know of: Kevin Igoe on the CFRG.
Trevor Perrin broke this down in amazing detail, mining posts out of several IETF mailing lists. Probably nobody is ever going to use Dragonfly in the real world, but watching people pick apart a new crypto protocol in public is amazing and hugely educational. I highly recommend reading this post:
But more importantly, nobody uses TLS-SRP. No browser implements it. The demand for PAKE authentication in TLS is not strong.
I'd argue that there's no demand for TLS-SRP because most of the people who could make use of it don't even know it exists. (Conventional thinking is that the only way to do authentication in TLS is with X.509. TLS-PSK has the same problem.)
But applications can't reasonably support TLS things that the TLS libraries they use don't support. Two of the three elephants in the TLS room, SChannel and NSS, don't support TLS-SRP. The other elephant, OpenSSL, has supported it for less than two years.
There's interest in (and patches for) adding TLS-SRP support to NSS, but they don't seem to want to implement anything that Firefox won't use:
(As an aside, I think NSS's position on supporting TLS-SRP highlights the biggest problem with chaining your code to a library produced by another entity for their own use: unless you have the ability to fork and maintain it yourself, your future use of that library is at the mercy of the other entity's interests. Fedora is porting all of their TLS-using packages to Mozilla's NSS, a project that exists for other Mozilla products' benefit. node.js is joined at the head to Google's V8, a JavaScript engine that exists for Chrome's benefit. My crystal ball shows both situations ending very badly when these projects' needs and directions get far enough out of alignment.)
You've already gave us background on who Trevor Perrin is.
Could someone shed a bit more light on who Dan Harkins is? He seems to be quite arrogant and does not address Trevor Perrin's criticism very constructively. See the other two threads started by Trevor:
My take on PAKE: it's a way to establish a shared key (KE), authenticating each other with a password (PA). The shared key could then be used to build a secure channel.
Believe it or not, I've seen many people thinking that KE alone is enough to build a secure channel. This misconception is probably as widespread as encryption provides message integrity. One needs to know he's talking to the right person, otherwise he's vulnerable to some man in the middle.
There are many ways to solve this authentication problem. A large number of TLS ciphersuites uses PKI, but there are also ciphersuites using pre-shared key or password such as TLS-PSK or TLS-SRP. PAKE protocols use a password to authenticate each other, e.g., if only Bob could know the password he's the only one could finish the protocol with Alice.
Recently I've worked on some authenticated key exchange problems not using a password, which could be fun to think about:
1) How to build a secure inter-app channel on iOS.
2) How to bootstrap keyboard-less devices to password-protected WIFI network.
"But more importantly, nobody uses TLS-SRP. No browser implements it."
And it is sad, even if it would be an interesting UI challenge to make it usable. However, I've seen TLS-SRP used in a machine to machine context (specifically home automation), where e.g. it would be too difficult to provision certificates or because a x509 library is just too big.
>The trouble with that is, nobody knows why we would want to add Dragonfly to TLS. TLS already has a PAKE option, SRP. [...] nobody uses TLS-SRP. No browser implements it.
SRP exists under a cloud of patent uncertainty. A lot of people would like to use SRP (perhaps not with TLS, but for SSH— for example) but deployment has been deterred by patent concerns.
I was intentionally a bit vague there because I didn't want to lend additional credibility to those concerns, especially without researching the current status.
Though IIRC only the limited form of SRP which doesn't provide bidirectional authentication (e.g. where you can't be MITMed even by a sever that knows your password or has stolen the server's 'hash' database) was covered under the royalty free grant. Implementation of the full protocol required a license from Stanford, https://ietf.org/ipr/31/
I'm in no way a cryptographer, so I don't understand the point of PAKE. The purpose is to build a secure channel between two entities, out of unsecure channels. But PAKE needs the reliable transmission of a secret information, so a secure channel has to be made before AND that secret needs to remain secret (duh)... What is the functional advantage over good ol' certificates (which still need the first, but are far less restrictive about the second) ?
The typical usage I've seen is one entity controlling both ends of the communication (e.g. an IP camera and a server). The secret being provisioned at the installation of the system.
I've never seen it used by humans, but there are contexts were the secure channel to establish the secret exists, e.g. most banks still have large brick and mortars infrastructures, so do tax authorities...
SRP used to authenticate sites and users would make phishing as we know it obsolete, but it would have to be implemented very carefully in the browser so there is no way whatsoever for a website to mimic its password entry UI...
But given the abysmal security record of the PKI model (were a few bad apple really ruin it for everyone else), the world could use a lot more SRP deployment...
What gets transmitted during key exchange is not the final symmetric key, but a kind of work-in-progress that both parties finish off to generate the final key, either by password, PK or any other method. No secure info is ever transmitted.
