Biz & IT —

Critics: NSA agent co-chairing key crypto standards body should be removed (updated)

There's an elephant in the room at the Internet Engineering Task Force.

Critics: NSA agent co-chairing key crypto standards body should be removed (updated)

Security experts are calling for the removal of a National Security Agency employee who co-chairs an influential cryptography panel, which advises a host of groups that forge widely used standards for the Internet Engineering Task Force (IETF).

Kevin Igoe, who in a 2011 e-mail announcing his appointment was listed as a senior cryptographer with the NSA's Commercial Solutions Center, is one of two co-chairs of the IETF's Crypto Forum Research Group (CFRG). The CFRG provides cryptographic guidance to IETF working groups that develop standards for a variety of crucial technologies that run and help secure the Internet. The transport layer security (TLS) protocol that underpins Web encryption and standards for secure shell connections used to securely access servers are two examples. Igoe has been CFRG co-chair for about two years, along with David A. McGrew of Cisco Systems.

Igoe's leadership had largely gone unnoticed until reports surfaced in September that exposed the role NSA agents have played in "deliberately weakening the international encryption standards adopted by developers." Until now, most of the resulting attention has focused on cryptographic protocols endorsed by the separate National Institute for Standards and Technology. More specifically, scrutiny has centered on a random number generator that The New York Times, citing a document leaked by former NSA contractor Edward Snowden, reported may contain a backdoor engineered by the spy agency.

Enter Dragonfly

Less visibly, the revelations about the NSA influence of crypto standards have also renewed suspicions about the agency's role in the IETF. To wit: it has brought new urgency to long-simmering criticism claiming that the CFRG was advocating the addition of a highly unproven technology dubbed "Dragonfly" to the TLS technology websites use to provide HTTPS encryption. Despite a lack of consensus about the security of Dragonfly, Igoe continued to champion it, critics said, citing several e-mails Igoe sent in the past two years. Combined with his ties to the NSA, Igoe's continued adherence to Dragonfly is creating a lack of confidence in his leadership, critics said.

"Kevin's NSA affiliation raises unpleasant but unavoidable questions regarding these actions," Trevor Perrin, a crypto expert and one of the most vocal critics, wrote Friday in an e-mail to the CFRG list serve. "It's entirely possible these are just mistakes by a novice chair who lacks experience in a particular sort of protocol and is being pressured by IETF participants to endorse something. But it's hard to escape an impression of carelessness and unseriousness in Kevin's work. One wonders whether the NSA is happy to preside over this sort of sloppy crypto design."

Update: In an e-mail sent several days after this article was published, McGrew wrote:

Recently, several people have commented that they feel that it is inappropriate for the role of Internet Research Task Force (IRTF) Crypto Forum Research Group (CFRG) co-chair to be filled by an NSA employee, whether or not he has only good intentions, because of the Snowden
BULLRUN revelations. It is important that each chair have the trust of the Research Group and the broader community, and there is ongoing discussion on this issue in the CFRG and among the IRTF and IETF leadership. The issue was originally raised by Trevor Perrin. He had
some legitimate differences with other participants over technical issues, and when he felt that his comments were being ignored by Kevin while he was acting in his role as chair, he interpreted this as evidence that Kevin was actively working to undermine the standards process regarding the Dragonfly protocol. I have not seen any such evidence; if I did, I would also be asking for Kevin's resignation myself.

Like the Dual EC_DRBG standard adopted by NIST and now widely suspected to contain a backdoor, Dragonfly came with no security proof. And unlike several other better known candidates for "password-authenticated key exchange" (PAKE), most people participating in the CFRG or TLS working group knew little or nothing about it. TLS already has an existing PAKE called SRP, which critics say makes Dragonfly particularly redundant. PAKEs are complex and still not widely understood by crypto novices, but in essence, they involve the use of passwords to negotiate cryptographic keys used in encrypted TLS communications between servers and end users.

Update: Dragonfly developer Dan Harkins strongly defended the security of the PAKE.

"There are no known security vulnerabilities with dragonfly," he wrote in an e-mail after this article was first published. "But it does not have a formal security proof to accompany it, unlike some other PAKE schemes. So the TLS working group asked the CFRG to look at it. They were not asked to 'approve' it, and they weren't asked to 'bless' it. Just take a look and see if there's any problems that would make it unsuitable for TLS. There were comments received on the protocol and they were addressed. There were no issues found that make it unsuitable for TLS."

Harkins also took issue with characterizations by critics and this Ars article that Dragonfly is "untested" and "highly unproven." He said it's used in the 802.11 Wi-Fi standard as a secure, drop-in replacement for WPA-PSK security protocol. It's also found as a method in the extensible authentication protocol and as an alternative to pre-shared keys in the Internet key exchange protocol.

"Do you know of another PAKE scheme that has been so widely applied?" he wrote in his response.

Perrin is a programmer who primarily develops cryptographic applications. He is the developer or co-developer of several proposed Internet standards, including trust assertions for certificate keys and the asynchronous protocol for secure e-mail. In Friday's e-mail, he provided a raft of reasons why he said Igoe should step down:

1) Kevin has provided the *ONLY* positive feedback for Dragonfly that can be found on the CFRG mailing list or meeting minutes. The contrast between Kevin's enthusiasm and the group's skepticism is striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based on. There's no record of Kevin making any effort to understand Dragonfly's unusual structure, compare it to alternatives, consider possible use cases, or construct a formal security analysis.

2) Twice Kevin suggested a technique for deriving the Dragonfly password-based element which would make the protocol easy to break [IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid timing attacks by adding extra iterations to one of the loops [IGOE_3, IGOE_4]. These are surprising mistakes from an experienced cryptographer.

3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG consensus, which was skeptical of Dragonfly [CFRG_SUMMARY].

Perrin's motion has been seconded by several other participants, including cryptographer William Whyte. Another critic supporting Igoe's removal called on security expert Bruce Schneier to replace Igoe. In an e-mail to Ars, Schneier said he is unsure if he is a suitable candidate. "I'm probably too busy to chair, and I'm not really good at the whole 'organizing a bunch of people' thing," he wrote.

In Harkins 1,117-word response, he wrote:

The opposition to it in TLS is not "long-simmering" as alleged in the article. It is very recent and the most vocal critic actually didn't say anything until _after_ the close of Working Group Last Call(a state of draft development on the way to RFC status). As part of his critique, Trevor Perrin has noted that dragonfly has no security proof. That's true and it's certainly not new. Having a formal proof has never been a requirement in the past and it is not a requirement today. He has continued to refer to the comments received about the draft as if they are signs of flaws. This is especially shocking given he is referred to in the article as "the developer or co-developer of several proposed Internet standards." Someone who develops, or co-develops Internet Standards knows how the sausage making works. Comments are made, comments are addressed. There has, to my knowledge, never been an Internet Draft that's perfect in it's -00 revision and went straight to publication as an RFC. His criticism is particularly mendacious.

Trevor Perrin has also points out the technique in which dragonfly generates a password-based element as being flawed. The technique was the result of a 2 year old thread on the TLS list on how to address a possible side-channel attack. Trevor doesn't like it, which is fair, but on the TLS mailing list he has also said that even if it was changed to a way he wants he would still be against dragonfly.

Anyone who has spent any time at all watching how standards bodies churn out the sausage knows that suspicions and vast conspiracy theories are almost always a part of the proceedings. But in a post-Snowden world, there's new legitimacy to criticism about NSA involvement, particularly when employees of the agency are the ones actively shepherding untested proposals.

This article was updated to add comments from Dan Harkins and David McGrew.

Channel Ars Technica