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
From: ianG <iang[at]iang.org>
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
>>>> There is really no problem with a trusted proxy, the question
>>>> whether the proxy is trustworthy or not. Consider the
>>> At the risk of getting my head bitten off for stating the obvious,
>>> might be worth demonstrating the difference between a trustworthy
system and a trusted system rather more
>>> 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
>> broadly I suspect, any committee
> Well, if we change the words a little, the government world has
> made the distinction between:
> - certification (tested), and,
> - accreditation (formally approved)
> And there are lots of cases of accredited system that are not
> or at least only loosely certified. (The Designated Approving
> signed the paperwork.)
> Those kind of map onto trustworthy (tested, certified) vs. "trusted"
> have to use this one, the General says so).
> And last time I looked, a lot of the folks who focus on security in
> 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.
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 .
2. the competition, or the no-holds-barred knock-out .
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.
 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.
 AES is the great example. SHA3 is another. CAESAR is coming.
The cryptography mailing