[Cfrg] should the CFRG really strive for consensus?

Christoph Anton Mitterer <calestyo@scientia.net> Wed, 31 December 2014 13:50 UTC

Return-Path: <calestyo@scientia.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 90BD41A8AEF for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 05:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YMcGyRvPKHrj for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 05:50:19 -0800 (PST)
Received: from mailgw01.dd24.net (mailgw01.dd24.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89F61A8ADE for <cfrg@irtf.org>; Wed, 31 Dec 2014 05:50:18 -0800 (PST)
Received: from localhost (mailpolicy-02.live.igb.homer.key-systems.net []) by mailgw01.dd24.net (Postfix) with ESMTP id 7CF135FAC7 for <cfrg@irtf.org>; Wed, 31 Dec 2014 13:50:17 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net
Received: from mailgw01.dd24.net ([]) by localhost (mailpolicy-02.live.igb.homer.key-systems.net []) (amavisd-new, port 10235) with ESMTP id B6ELY_tnSeeA for <cfrg@irtf.org>; Wed, 31 Dec 2014 13:50:07 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-93-104-116-14.dynamic.mnet-online.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for <cfrg@irtf.org>; Wed, 31 Dec 2014 13:50:07 +0000 (UTC)
Message-ID: <1420033807.4638.16.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Date: Wed, 31 Dec 2014 14:50:07 +0100
In-Reply-To: <CAMfhd9V4tnjQL-orjTjX3KS=-XZRn0snAPrVwmP6pZH_20Cfgg@mail.gmail.com>
References: <CAMfhd9V4tnjQL-orjTjX3KS=-XZRn0snAPrVwmP6pZH_20Cfgg@mail.gmail.com>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-K1yknwVcjwpQLfmoGZxl"
X-Mailer: Evolution 3.12.9-1
Mime-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1_YUddy-7UB_zCQPLGi7p7k9XzA
Subject: [Cfrg] should the CFRG really strive for consensus?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Dec 2014 13:50:21 -0000


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


> 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

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