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

[Jerry Leichter]

On Aug 3, 2015, at 7:41 PM, Stephen Farrell <stephen.farrell at cs.tcd.ie> wrote:
> Hiya,
> 
> On 03/08/15 22:33, Jerry Leichter wrote:
>> 2.  There's a (pre-determined) cutoff time after which no new proposals can be entered.
> 
> That could work in some place but not in the IETF. (Although there are
> timers and cutoffs involved in the nominal IETF process.)
> 
> In the IETF we have a theory, which is actually fairly well reflected
> by practice, that any decision can be overturned by a sufficiently
> compelling new fact. That has not infrequently resulted in work being
> sent back to working groups at IETF last call time when a different
> set of folks not involved in the working group get to describe their
> views of the downsides of some thing or other.
If you have a new proposal that's sufficiently better than all the existing ones, showing that it is so amounts to an attack against the existing proposals, knocking them out of the competition.  (There's no formal definition of "an attack".  It doesn't *have* to show a weakness - showing that you can do much better is sufficient.)

Presumably you then restart the competition.

Just allowing new proposals - even proposals that will rapidly be knocked out of the running - to be mooted forever allows anyone to delay the process indefinitely.  In effect, what I'm suggesting is that after the cutoff, the only way to get a proposal in is by getting it recognized as significantly better than what's already there - a deliberately high barrier.  Treating this as an attack just lets you do it without invoking some new ad hoc mechanism for judging what's "better by enough":  It's decided by the same people, in the same way, that they judge when an attack that looks like and attack is "significant".

> I think overall the benefit of being fact-based regardless of how much
> it buggers up progress is more significant than the potential for fixed
> timings such as you've suggested to mitigate an action taken as part of
> an invisible bullrun attack. (Once again, I assert that we need to not
> try consider bullrun in isolation, but we need to try our best to
> counter all methods of gaming the system without worrying about the
> unkonwable details as to why someone may be gaming the system.)
These deadlocks arise often enough even without a deliberate attack that having a way to deal with them is important.  At some point, *any* decision is better than *no* decision.  (Or it isn't.  Sometimes what you learn from the process is that this is decision you don't need to make about a protocol - or whatever - that you don't need.  The way this tends to play out is that eventually most of the participants who were so eager at the start fade away, realizing that the effort is just not worth their while.)

> That said, I do agree that there's usually a giant debate about what
> are in fact the facts in most such situations, so YMMV in terms of
> what reasonable folks can conclude on this point.
                                                        -- Jerry