Donate for the Cryptome archive of files from June 1996 to the present

22 July 2014

The Heart of Crypto Failure Is Committee Design

Date: Tue, 22 Jul 2014 10:51:48 +0100
Subject: Re: [Cryptography] The role of the IETF in security of the Internet: for or against the NSA? for or against the security of users of the net?
From: ianG <iang[at]>
To: cryptography[at]

On 20/07/2014 18:16 pm, Miles Fidelman wrote:

> ianG wrote:
>> On 19/07/2014 20:26 pm, Dave Horsfall wrote:
>>> On Sat, 19 Jul 2014, Phillip Hallam-Baker wrote:
>>>> There is really no problem with a trusted proxy, the question is
>>>> whether the proxy is trustworthy or not. Consider the following
>>>> possibilities:
>>> At the risk of getting my head bitten off for stating the obvious, it
>>> might be worth demonstrating the difference between a trustworthy system and a trusted system rather more succintly:
>>> A trustworthy system is one that you *can* trust; a trusted system is one that you *have* to trust.
>> This has never been obvious, at least not to the IETF WGs, or more
>> broadly I suspect, any committee approach.
> Well, if we change the words a little, the government world has always
> made the distinction between:
> - certification (tested), and,
> - accreditation (formally approved)
> And there are lots of cases of accredited system that are not certified,
> or at least only loosely certified. (The Designated Approving Authority
> signed the paperwork.)
> Those kind of map onto trustworthy (tested, certified) vs. "trusted" (we
> have to use this one, the General says so).
> And last time I looked, a lot of the folks who focus on security in the
> IETF context, play in that world.

It's curious, isn't it. To argue perhaps contrarily:

The essence of good security design is to (a) solve what problems we can in software, completely, and (b) provide tools to the users to solve the ones we can't do automatically.

In the early days of the net, we were told which algorithms we were allowed to use. People started shipping 'export' versions and 'domestic' versions. Which opened the door to algorithm agility, today's hobby horse, into which everyone piled in their philosophical desires.

So we (a) solved the protocol parts in software and (b) kicked the choice of algorithm up to layers 8 & 9.

The result was disaster. It wasn't just SSL. IPSec suffered from over-engineering-by-committee. OpenPGP failed to move forward; it spent 10 years in RFCland, trying to cater for the fashion trade in algorithms, amongst other things like five ways to say one.

The heart of the matter is the committee design: it finds itself having to let in many little devils in order to please everyone, including people not in the committee. In order to reach consensus, too much is accepted; is rough consensus the solution? Or the problem?

Let me speculate on TCPinc. Clearly, TCP that bootstraps a DH key exchange in the startup phase and then encrypts packets with a ChaCha20/Poly1305 suite will work to knock out mass surveillance. It will be small enough and tight enough to be provable and fit in a kernel without angst. Easily codable. Popular.

It meets all useful criteria *except the committee one*.

Just as clearly, I speculate that the above will not survive the IETF working group process. In order to get that rough consensus, everyone must be pleased and everyone must get their favourite thing in there. There's already 4 proposals, and at least two of them are "my favourite kitchen sink..."

We know of two paths to success:

1. the dictatorial, or "trusted" path, being we have to use this one, or the General told us so [0].

2. the competition, or the no-holds-barred knock-out [1].

The open consensus process may have done its dash, the recent successes have used the competition process.

The challenge for the IETF especially security Area is to face up to this dilemma. Maybe time for IETF to change the rules, or the game. Shooting from the rough should be part of game, not a way for insiders to push people out into impossible positions.


[0] John Kelsey pointed out some successes where decisions were made by a tight team. Unix by 2 guys, Linux by one, Bitcoin by one, SSH by one, etc. TCP wasn't originally written by committee, it was written by a company under contract to DARPA. Indeed cryptography has many lessons in single directors: DES, SHA1, SHA2. The ChaCha family. Mostly a positive story.

[1] AES is the great example. SHA3 is another. CAESAR is coming.


The cryptography mailing list