Re: [Cfrg] should the CFRG really strive for consensus?

"Salz, Rich" <rsalz@akamai.com> Wed, 31 December 2014 16:29 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8911A923D for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 08:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-WV16ASbzqH for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 08:29:24 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 237281A000B for <cfrg@irtf.org>; Wed, 31 Dec 2014 08:29:23 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3F50247653; Wed, 31 Dec 2014 16:29:22 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2C0404764E; Wed, 31 Dec 2014 16:29:22 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 205A580047; Wed, 31 Dec 2014 16:29:22 +0000 (GMT)
Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 31 Dec 2014 11:29:03 -0500
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 31 Dec 2014 11:29:03 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Adam Langley <agl@imperialviolet.org>, Christoph Anton Mitterer <calestyo@scientia.net>
Date: Wed, 31 Dec 2014 11:29:00 -0500
Thread-Topic: [Cfrg] should the CFRG really strive for consensus?
Thread-Index: AdAlCFs/4Bq9HNWURfmkBpSKURqQhwADhmmg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55237255@USMBX1.msg.corp.akamai.com>
References: <CAMfhd9V4tnjQL-orjTjX3KS=-XZRn0snAPrVwmP6pZH_20Cfgg@mail.gmail.com> <1420033807.4638.16.camel@scientia.net> <CAMfhd9V5-Y60fGqCDfmCvk9+9bqm0zpm3kSHmR5_mzELZ2K+Dw@mail.gmail.com>
In-Reply-To: <CAMfhd9V5-Y60fGqCDfmCvk9+9bqm0zpm3kSHmR5_mzELZ2K+Dw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dbh9dYQijWdOQk5pFt06hEHSEfU
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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 16:29:25 -0000

> IRTF groups do not, technically, have to reach consensus. However, everyone does have to function on the same Internet at the end of the day.

Neither does the IETF.  As I recall, the phrase is rough consensus.  At least as regards X25519, I think it's pretty obvious that Microsoft is in the rough.

As a security person, not a cryptographer by any stretch of anyone's imagination, this is starting to look like we are trying to find a way to "give them something" so that they can save face.

I think the proper way to phrase the question is this:  are there any security objections to the currently deployed X25519?  Either I haven't seen any, or I haven't understood them.  The only objections have been that they don't fit into a framework.

	/r$

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz