[Cfrg] should the CFRG really strive for consensus?

[Christoph Anton Mitterer <[e-mail]>]

Hi.

On Wed, 2014-12-31 at 13:27 +0000, Adam Langley wrote: 
> Microsoft accepts 

vs.

> Everyone else accepts


When following the list recently, a recurring issue that seemed to
dominate the discussions is "Microsoft vs. everyone else" and the urge
to reach consensus.


In principle consensus is of course a good thing, since a new standard
or recommendations would be accepted by everyone, but it's also kinda
disturbing when one big player can apparently basically block what
nearly all others would already agree upon.


But in the light of the NSA&friends scandal which basically gave the
CFRG it's purpose (since it became all too obvious that NIST is
untrustworthy per se)

... and in the light of governments being able to easily control&command
companies from at least their own country with secret court orders, gag
orders etc.
... and in the light that we've already seen government agencies
disturbing crypto/security standards indirectly via straw men

I think it's really a bad idea for the CFRG to strive so much for
consensus.


It basically leads us back to the original problem of simply taking
standards from NIST, in that we don't know whether changes wich seem
harmless and not affecting security actually do for someone who may
posses some more knowledge already.
And even if not, one fraction shouldn't be able to block things for so
long, which in a higher level way also undermines security.


Microsoft (and others) may surely be big players, but what should really
count for the CFRG and for a good standard/recommendation is now how
revenues a player has, but rather how many crypto-experts actually voice
and prove their arguments/objections/etc..
And from that POV Microsoft doesn't look like *that big* player anymore.

The main task of CFRG should be to give as good as possible
recommendations/standards.
Whether these standards are actually taken up in the end by the big
players in their products is completely up to them and not even
guaranteed when consensus would have been reached.
Which is just another reason, not to make (possibly bad) compromises.



Cheers,
Chris.