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

Stephen Farrell stephen.farrell at cs.tcd.ie
Sun Aug 2 07:33:23 EDT 2015


On 02/08/15 05:27, ianG wrote:
> It turns out that there is a really nice attack.

Also trying to keep away from specifics of any one protocol.

In general you assume that the attacker (who I agree exists) is active
as part of the process. There's no way to know the probability of
that. I do know that people have the ability and propensity to disagree
with one another for all sorts of reasons that are nothing to do with
the posited attacker. Perhaps especially the kind of people who
currently dominate discussions about new Internet protocols. And even
more especially in fully open environments where anyone can try to
participate. And since the new work represents change, and for some
folks, significant change, it's entirely likely that genuine
differences of opinion will exist even without any action from the
attacker.

There is also the fact that any rough consensus process has to be
run by fallible humans. Not everyone is good at herding cats so that
the cats agree they have arrived at rough consensus. So in addition
to genuine technical disagreement one also has to take into account
the chances of accidental mis-management. IMO, that probability is
also quite high - not every engineer ends up being good at cat
herding sadly;-)

Lastly, given there are a whole bunch of proposals and bits of work
being done in parallel, it's entirely to be expected that at least
one of those gets stuck because of some process-stupidity.

All of the above argues that we need be very realistic and quite
well informed to arrive at a realistic evaluation of whether or not
they might be an active attack being attempted against a specific
proposal.

To move to slightly more specifics, you mention rough consensus so
I assume you're talking mainly about the IETF, since the IETF is
afaik the only set of folks that use "rough consensus" as a term of
art.

In the case of the many bits of good work that are being done to improve
security and privacy in the IETF, I do think it's quite likely
that some but not all people working for signals intelligence agencies,
and/or companies who work with them, do disagree with some of that
work. Some of that disagreement is openly expressed I'm sure and
that's just fine - we can handle openly expressed technical
disagreement fairly easily, if not perfectly.

Since there are only a tiny number of direct employees of signals
intelligence agencies who participate in the IETF, and those folks
are generally not trying to game the system in obvious ways, (I
think I would notice if they were, 'cause yes I look out for it:-),
I think we can ignore them here. Three are however a lot of esp.
large companies who work with/for signals intelligence agencies
and who do participate in the IETF, so I'll focus on those since
any sensible attack would be done via a player like that.

In any such case, my experience is that perceived commercial advantage
(which may be long term) is what causes such participants to try
to game the system. And indeed working with signals intelligence
agencies is presumably profitable, so there is the potential for
this attack. (One can argue that individuals within such enterprises
may be used in an attack by leveraging their inflated egos etc,
and that's true, but is indistinguishable from other personality
related reasons to disagree so is covered above I think.)

The remaining question then is whether or not people from commercial
enterprises are, in addition to openly participating as expected,
attempting to manipulate the open process to their own commercial
advantage. And the answer is yes, of course they are, as always. But
is that only because of the signals intelligence agencies? No it is
not. For any of the relevant players, which includes basically all
large companies, they have many more interests in play and it's not
possible to disentangle those from the outside. (Or even from inside
sometimes I bet:-)

So it's impossible to tell what has motivated any particular bit of
process gaming, and it's mostly silly to bother asking. That's just a
part of operating in the big bad world, once you get beyond the playing-
with-friends stage of any project you can't worry about the motivations
of all participants. (You can decide if specific folks are worth
worrying more about and pay more attention to technically examining
their inputs, that's IMO fine, and I do that, but not based on current
employer, rather based on a pattern of contributions.)

Basically, we can describe what we consider good behaviour but we need
to recognise that clever people will figure out ways to try to game any
system for reasons we can't know, so worrying about all motivations is
counter-productive, we need to examine visible actions and not worry
about the unknowable.

> The only defence I can see is to drop rough consensus.  

IMO that would not be a defensive move. That represents surrender.

And not only of the rough consensus approach. To have any effect you
would also have to surrender openness and decide who to allow into
your secret cabal. That kind of cabal doesn't scale IMO. (The outputs
of such cabals can be and often are useful inputs to the open rough
consensus process that the IETF uses, so secret cabals are not all
bad:-)

With your surrender proposal, the putative attacker wins as there
would no longer be an organised way to produce new protocols that are
likely to fairly quickly see widespread deployment. In that case
instead of heading towards 99% deployment in some reasonable timeframe,
it's much more likely that 2% is a potential high-water mark. There may
be exceptions but those will be exceptions. (And yes, we're both
pulling numbers from the air.)

I do agree that over time things like the IETF will evolve or perish
and the concepts of rough consensus and openness ought be part of
that evolution. (For example, the IETF IMO needs to figure out how
to consider the views of users who are not engineers, but I don't
know how to do that today.)

So one can sensibly work towards a world where things like the IETF
evolve more to one's liking, or one can sensibly work to try create
something else to fill the niche currently filled by e.g. the IETF.

But simply suggesting dropping rough consensus is nonsense, any
credible attempt to avoid the posited attack would need to also
say how you'd effectively replace the whole of the IETF if you're
not proposing some feasible evolution within the IETF.

> By offering
> rough consensus, it's almost a gilt-edged invitation to the attacker.
> The attacker isn't so stupid as to not use it.
> 
> Can anyone suggest a way to get around this?  

Yes. Where you think it sufficiently important you should participate
in the rough consensus process with sound technical argument about the
technical proposals made. That is IMO far more effective as a way to
counter the attacker, compared to surrender.

And if you get really exercised about all this and are a masochist
you can participate in trying to evolve things like IETF processes.
That's not for everyone by any means, and is a recipe for learning to
deal with frustration, but is the kind of worthy-but-tedious stuff
that does actually need to be done to improve the rough consensus
open approach to improving the Internet.

And for things where you can't participate (time available being
finite), to the extent you can, refuse to use the outputs of the
process that you don't like or doubt, and tell other folks (the
technically sounds reasons) why and recommend they do likewise. (I.e.
sure, go ahead and make noise about the actual bad features of outputs
from  the process.) That can produce change in those who do participate
in the parts of the work that you can't get to helping with or that
you don't care that much about.

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

Your argument is ill-informed and incomplete and your conclusion is
erroneous. (That's my thought anyway:-)

Cheers,
S.




More information about the cryptography mailing list