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

Nico Williams <nico@cryptonector.com> Wed, 31 December 2014 22:14 UTC

Return-Path: <nico@cryptonector.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 236C31A1A6D for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 14:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 nmAbkukavYQp for <cfrg@ietfa.amsl.com>; Wed, 31 Dec 2014 14:14:25 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 60B7E1A1A47 for <cfrg@irtf.org>; Wed, 31 Dec 2014 14:14:25 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C6CC021DE58; Wed, 31 Dec 2014 14:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2u9HI+tV0cNHPS /poOZo3nsPHVc=; b=MJi+D0ZjaWVlzPGEROuwo+FNJh0+aLU50UfToJu4VNlrCw IfaCc35qQGbepuMzFBUOmfUnXXZtUG0PUfjMfBZUXc8CjK84bdZjSeY1zHGNPfPI pG9c4MKga7fDuZ9mp4JLctecoRkv6QFLg+N93JUNnNpzBag0q8iuBlnj5oOTU=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id 6B02821DE57; Wed, 31 Dec 2014 14:14:24 -0800 (PST)
Date: Wed, 31 Dec 2014 16:14:23 -0600
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20141231221420.GX24442@localhost>
References: <CAMfhd9V4tnjQL-orjTjX3KS=-XZRn0snAPrVwmP6pZH_20Cfgg@mail.gmail.com> <1420033807.4638.16.camel@scientia.net> <CAMfhd9V5-Y60fGqCDfmCvk9+9bqm0zpm3kSHmR5_mzELZ2K+Dw@mail.gmail.com> <1420042774.10106.10.camel@scientia.net> <CACsn0c=jEXhbUQt7FqZ_KqYQqq0NJsdZow=TEZ2G0te2SUb0RA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACsn0c=jEXhbUQt7FqZ_KqYQqq0NJsdZow=TEZ2G0te2SUb0RA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/npALl9NphnToaMGKmshcay4o_ao
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 22:14:26 -0000

On Wed, Dec 31, 2014 at 04:26:22PM -0500, Watson Ladd wrote:
> What people might not be aware of, particularly if they joined the
> list late, is that we've been discussing all of these proposals
> (except for 2^389-21) since April. Nothing new has been discovered.
> Yet we've missed two self-imposed deadlines, and have no visible plan
> to actually meet hard external deadlines, coming close to a year since
> we decided to start.
> 
> Why? Unclear. We've had requests since 2010 to add X25519 to TLS. In
> the meantime, Brainpool and ANSSI curves got added without this mess.
> Why are we treating Curve25519 differently from these national
> standards? And why did it take so long for the initial request to get
> sent to CFRG? Irrelevant the problem we face now, but interesting in
> considering how avoid it in the future, or, punt it to someone else.
> 
> The CFRG is potentially very good at answering questions about
> security. But we shouldn't be surprised that it is bad at having to
> make choices, particularly when one group remains determined to stay
> in the running by consistently modifying its proposal as issues are
> raised. [...]

The IETF will allow the use of many modern cryptographic algorithms, but
wants to have a limited number of REQUIRED to implement ones.  This is a
good thing: it limits the amount of work needed to produce interoperable
implementations of Internet protocols while still giving us usable
algorithm agility (if there are more than one RTI algorithms; IMO there
should be at least two for each class).

If the IRTF in general, or CFRG in particular are bad at making
recommendations about REQUIRED to implement algorithms, then CFRG should
limit itself to reporting what it has learned -- let the IETF make the
engineering decisions.

That's what I'd expected anyways.  Why are we making this harder than it
needs to be?

Let the IRTF publish one or more documents describing various curves
suitable for use in Internet protocols.  The IETF can pick from among
those.

Nico
--