Two things you did not know before this post but know now:
* The IETF has a dedicated crypto review board, the CFRG, which approves or pokes holes in the cryptography used by other IETF standards.
* The chair of the IETF CFRG is an NSA employee (Kevin Igoe, one of the authors of the SHA1 hash standard).
I just learned these things a couple weeks ago. I am not generally a believer in the theory that NSA actively subverts Internet standards†. But even I think that it's crazy for an NSA employee to chair the CFRG.
In case you're wondering: Trevor Perrin is widely respected professional cryptographer. Most cryptographers work for university math departments. Perrin worked for years as a staffer for Paul Kocher, the godfather of side channel attacks, at Cryptography Research. He's the designer of the new forward secrecy ratchet for OTR (Axolotl) and the TACK TLS extension, and a behind-the-scenes contributor to other IETF crypto standards. Perrin wrote the pure-Python "tlslite" TLS implementation. If you were to draw a "family tree" of crypto know-how in the software security profession, a surprisingly huge chunk of it would be rooted in Perrin (and Nate Lawson and Kocher); for instance, virtually every modern TLS break came from ideas that Perrin popularized. 64 current Matasano Crypto Challenges, probably 50 of them I can trace to Perrin and Lawson. Trevor Perrin is someone you should pay attention to.
† (my best guess is that the standards NSA was actively subverting were about international telephony; subverting the IETF is a little like subverting the Linux kernel --- doable, but bad tradecraft)
> subverting the IETF is a little like subverting the Linux kernel --- doable, but bad tradecraft
This is a great point. The mailing list and public nature of the standards process makes it very difficult to subvert, without very high risks of getting caught and breaking trust in the community. These agencies need to keep hiring good cryptographers and ideally keep bodies working on standards.
Shows the importance of OSS in security and having people like Trevor Perrin keeping watch.
But at the same time - if the NSA was going to subvert encryption standards - I doubt they would subvert the process with someone who is known to work at the NSA. Intelligence agencies would operate covertly. Most likely by converting someone trusted in the community into an agent, or grooming their own agent straight out of high school/university and getting them to a point of influence in the community (over a long period of time) and only then having them damage crypto standards. < this is standard tradecraft.
Bullshit. Subverting the Linux kernel would easily be within the capabilities of the NSA.
Kernel contributors aren't background-checked so all you need to do is to pay someone to do some legitimate kernel hacking in a sensitive area. Then in one of their commits slip in a backdoor.
"But noooo the many eyes will see the backdoor!" you say.
This is clearly false. If it were true Linux would have no security bugs at all. Since old security bugs continue to be found, it follows that it is possible to have a security bug that goes unnoticed for many years. See also the underhanded C contest.
Hell maybe it has already happened. Who is to say the latest Linux security bug wasn't deliberately introduced by the NSA?
I don't think this is paranoia - it would be fairly easy for the NSA to do, very useful and almost completely deniable. I would do it if I were them. They certainly wouldn't not do it for moral reasons because they've shown they don't really have any.
But if people are going to use the argument that they'd never use an NSA employee to subvert encryption standards, as you are doing here, that clears them to do just that.
Furthermore, before the Snowden revelations, they weren't under suspicion for trying to do that.
I see what you're saying, but it still doesn't make sense not to use someone with no visible ties. If you're going to go that deep, you would use the official employee as a red herring. You don't even want people to think about the possibility of your real guy being an agent, even in this weird convoluted way.
On the one hand, a background check should reject anyone with such a visible a conflict of interest; On the other IETF is full of U.S. nationals, so it's only trustable for countries with common interests with the U.S. Either way, the IETF reputation will be exactly constant before or after a decision is made.
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.
> I am not generally a believer in the theory that NSA actively subverts Internet standards†. But even I think that it's crazy for an NSA employee to chair the CFRG.
I am uncomfortable with the NSA / GCHQ being that closely tied to the standards process.
I'm much happier when they're noodling away with research in the background and providing support to universities.
An example: GCHQ invented PK before Diffie and Hellman. They invented RSA before RSA did. They kept both of these secret for many years. GCHQ's RSA was not revealed until 24 years later. (About 20 years after RSA had been in use).
So, secret government spy agencies keep secrets. I think this is as alarming as secret government spy agencies spy. While they might not actively subvert crypto standards would they allow weaknesses to be implemented without comment?
No. I believe I know the specific people to whom Gilmore is referring, and I believe his observations to be a straightforward result of incompetence. You have to have read the IPSEC working group list posts of the time and see how the group treated real cryptographers to understand how unnecessary it would have been for NSA to have corrupted that standard.
No, I don't think NSA tried to subvert IPSEC, and especially not in the way Gilmore describes.
I dunno. Packing standards bodies with incompetents and then suggesting things to those incompetents that are apparently sensible but weaken security seems like a perfectly plausible way of subverting cryptographic standards to me. Also, it probably wouldn't be terribly hard to seed a culture of disdain for real cryptographers.
Did you just use a "slippery slope" argument to argue against "slippery slopes?" I'm gonna chalk this up to "tongue-in-cheek," though I may be wrong...
He's saying that Gilmore was attributing to malice what Thomas believes more likely to be due to incompetence. He's not asserting that Gilmore is incompetent.
> subverting the IETF is a little like subverting the Linux kernel --- doable, but bad tradecraft
... and what kind of tradecraft, pray tell, is subverting a random number generator and planting it inside the BSAFE library after paying off RSA DSI with a $10 million dollar contract?
If the NSA is willing to do something like this, what is would it consider too unethical/immoral/bad tradecraft not to do?
It may be bad tradecraft to subvert IETF standards but it would be wholely inline with people trying to padd their yearly performance review. Given the questionable effectiveness of some of the programs, review padding seems very plausible.
subverting the IETF is a little like subverting the Linux kernel --- doable, but bad tradecraft
Unfortunately the fact it might be "bad tradecraft" doesn't seem to be much of an impediment for U.S. intelligence agencies. They seem to have a knack for getting caught with their pants down over stunts that one would think that cooler heads would have prevailed against as being not only reckless, but to have had the potential for, at the very best, marginal tactical benefit.[1],[2]
* The IETF has a dedicated crypto review board, the CFRG, which approves or pokes holes in the cryptography used by other IETF standards.
* The chair of the IETF CFRG is an NSA employee (Kevin Igoe, one of the authors of the SHA1 hash standard).
I just learned these things a couple weeks ago. I am not generally a believer in the theory that NSA actively subverts Internet standards†. But even I think that it's crazy for an NSA employee to chair the CFRG.
In case you're wondering: Trevor Perrin is widely respected professional cryptographer. Most cryptographers work for university math departments. Perrin worked for years as a staffer for Paul Kocher, the godfather of side channel attacks, at Cryptography Research. He's the designer of the new forward secrecy ratchet for OTR (Axolotl) and the TACK TLS extension, and a behind-the-scenes contributor to other IETF crypto standards. Perrin wrote the pure-Python "tlslite" TLS implementation. If you were to draw a "family tree" of crypto know-how in the software security profession, a surprisingly huge chunk of it would be rooted in Perrin (and Nate Lawson and Kocher); for instance, virtually every modern TLS break came from ideas that Perrin popularized. 64 current Matasano Crypto Challenges, probably 50 of them I can trace to Perrin and Lawson. Trevor Perrin is someone you should pay attention to.
† (my best guess is that the standards NSA was actively subverting were about international telephony; subverting the IETF is a little like subverting the Linux kernel --- doable, but bad tradecraft)