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

[ianG]

On 3/08/2015 21:34 pm, Simon Josefsson wrote:
> 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


So in essence, the group forks, and the running code teams pursue 
informational track rather than standards track.  The consensus battle 
shifts to the marketplace.

The attacker has presumably concentrated his forces on people who don't 
write the code.  So that thrust is only valuable in WG if the decision 
is kept within the WG.  As the running code teams leaves, they achieve a 
hollow victory.

OK, I get it.  This approach works if the big companies look at things 
from an engineering pov, and adopt the Informational doc on the merits. 
  It fails if the big majors hold out and it doesn't achieve scale.

(So if this attacker can also impact the majors, it's harder.  Although, 
one has to note, that even in the case of the WG coming to a conclusion 
and publishing the RFC, we still depend on the majors to deploy in order 
to reach market consensus / critical mass / effective deployment.  The 
majors are more likely to respond to a formal RFC;  eg at least one 
major declares only to follow standards, it won't save its users unless 
someone tells it how to do it by standard.)


> 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.


Right, so attacker downgrades the running code aspect in WG.  I think I 
see the tactic.


> 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.


Yup.  No "democratic group" ever is.  Sadly, a battle of dictators has 
more success in designing new stuff.  A "democratic group" is only 
useful when the group decides they are better off agreeing in a room 
what is the combined way forward, when the alternative is open warfare.

iang



ps;  There's something of hubris in the standards world.  They all seem 
to believe they can do more than resolving market battles into 
standards.  E.g., the British Standards Institute just recently came up 
and said they wish to start standardising cryptocurrencies.  The bind 
moggles.