[Cryptography] asymmetric attacks on crypto-protocols - the rough consensus attack

[Simon Josefsson]

Tom Ritter <tom at ritter.vg> writes:

> On 1 August 2015 at 21:27, ianG <iang at iang.org> wrote:
>> Can anyone suggest a way to get around this?  I think this really puts a
>> marker on the map - you simply can't do a security/crypto protocol under
>> rough consensus in open committee, when there is an attacker out there
>> willing to put in the resources to stop it.
>>
>> Thoughts?
>
> My opinion is that the rough consensus can be counter-balanced by
> "running code".  If the original group moves forward, deploys, gets
> early adopters, shows it's working, and perhaps wonder-of-wonders gets
> it picked up by one of the big behemoths that could jump-start
> deployment (maybe Google, or Akamai, or CloudFlare) - well they can
> document as an informational document at least.  And you can
> interoperate with the folks who have deployed.

+1

The "running code" approch could lead the attacker to change its modus
operandi to 1) attempt to get implementers/deployers out of the decision
making process, or at least sufficiently balanced with people who never
writes code or deploy code, combined with 2) attempts to stall
publication of implemented protocols.  Both are relatively cheap to
achieve in a good-faith organization by a bad-faith participant, and is
possible to do indirectly without being identified.  In the end you get
"rough consensus" decision-making, with the problems discussed here,
without the "running code" mitigator.  Success for the attacker.

The IETF is, I would argue, extremely good at refining/documenting
deployed protocols and resolving identified problems with them.  It has
never (or at least not as long as far as I've been around) been good at
designing things from scratch when the use-case is not clearly expressed
and agreed on.  Sadly it has not been good at learning from this history
either.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150803/0c7fd328/attachment.sig>