[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?

ianG iang at iang.org
Tue Jul 22 05:51:48 EDT 2014


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.



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.


More information about the cryptography mailing list