|
||||
|
22 July 2014 The Heart of Crypto Failure Is Committee Design
Date: Tue, 22 Jul 2014 10:51:48 +0100 On 20/07/2014 18:16 pm, Miles Fidelman wrote:
> ianG wrote: 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. iang [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
|
