[Cfrg] publishing drafts (was: Re: [CFRG] Safecurves v Brainpool / Rigid v Pseudorandom)

David McGrew <mcgrew@cisco.com> Tue, 14 January 2014 20:56 UTC

Return-Path: <mcgrew@cisco.com>
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 0FDAF1AE237 for <cfrg@ietfa.amsl.com>; Tue, 14 Jan 2014 12:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KSLRf81xgtPx for <cfrg@ietfa.amsl.com>; Tue, 14 Jan 2014 12:56:53 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1DCBC1AE19D for <cfrg@irtf.org>; Tue, 14 Jan 2014 12:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16070; q=dns/txt; s=iport; t=1389733002; x=1390942602; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ofbWCYRO6t3DK9cHTNuLjaEJrNY0J4E0Q87mBYJPOus=; b=FbdXQYfoxSEzYegr3jnCOZyhiL3yNvtAx7y42qwEELlHbGD5QPxLphds dqhNgEQsmkDpQ2JiS/ajxcjdda49x72aT3HqWNFNjtRWFRMFVijqRrMcO h9oZ42CSmfS5D38/e+4ddrGWPJ+DBDWbuNybHsma8762uW/ZDFOXMP19c A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.95,659,1384300800"; d="scan'208,217"; a="12828260"
Received: from rcdn-core2-2.cisco.com ([]) by alln-iport-1.cisco.com with ESMTP; 14 Jan 2014 20:56:38 +0000
Received: from [] (rtp-mcgrew-8914.cisco.com []) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EKubVt022557; Tue, 14 Jan 2014 20:56:38 GMT
Message-ID: <52D5A485.5090203@cisco.com>
Date: Tue, 14 Jan 2014 15:56:37 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Dan Brown <dbrown@certicom.com>
References: <810C31990B57ED40B2062BA10D43FBF5C1EA1B@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5C1EA1B@XMB116CNC.rim.net>
Content-Type: multipart/alternative; boundary="------------050703090903060200040500"
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] publishing drafts (was: Re: [CFRG] Safecurves v Brainpool / Rigid v Pseudorandom)
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: Tue, 14 Jan 2014 20:56:56 -0000

Hi Dan,

thanks for sharing your thoughts, more inline:

On 01/13/2014 11:55 AM, Dan Brown wrote:
> Last week I wrote that I would soon write up my disagreements with the 
> safe curves site.
> My first disagreement is written up below, but first two editorial issues:
> -My last email was in the context of Watson's draft spec for the 
> Chicago (Bernstein?) curves, but I would like to detach the issue from 
> the I-D.  My comment about the reference in Watson's I-D to a website 
> was just an editorial comment.
> -These technical issues that I hope CFRG discusses just might be 
> resolved and written into a CFRG I-D cataloging of elliptic curves and 
> their relative merits and so on, which should be independent of 
> Watson's spec for the Chicago curves.  For now, I opted to discuss via 
> email list, rather than placing these arguments into my own one-sided 
> individual I-D.  Please advise me if such an I-D is preferred to email.

This is an important question, so let me take a step back before I 
answer it.

You and others are welcome as individuals to contribute individual 
submission Internet drafts and call them to the attention of CFRG. If 
you want to provide a more formal document, then an I-D seems more 
appropriate, but I am personally fine with an email such as this one, 
when there is no need for a permanent record.

Technically, I-Ds are not permanent documents; they expire by design.  
Some I-Ds progress to become RFCs.   Progressing an I-D to an RFC takes 
a bit of work and patience, so ideally, we should minimize the number of 
documents we progress to RFC.

The research group can choose to take on an I-D, because it wants to 
endorse the work and make sure that it gets published.   However, it is 
not necessary to do that.   Alternatively, I-Ds that are individual 
submissions can get progressed to RFC, and can be reviewed in CFRG.    
This has been done before with CFRG, with RFCs 5116 and 6090 for 
instance.  The process for progressing drafts to RFCs is described in 
http://tools.ietf.org/search/rfc5742    If CFRG takes on a draft, then 
the CFRG chairs are responsible for performing or orchestrating the work 
that needs to be done to get it published as an RFC.   If someone wants 
to publish a draft as an individual submission RFC, rather than going 
through the CFRG process, then they will need to convince a Security 
Area Director (Sean or Stephen) to publish their draft.  Of course, one 
of the differences of authoring an individual submission instead of an 
RG draft is that, in the latter case, the author is accountable for a 
work product of the entire group (that is, the draft needs to reflect 
input from other RG members).

We need to be conscious of the limited resources that we have for 
reviewing and shepherding documents within CFRG, and make sure that we 
take on work that we can complete.   We are fortunate to have the 
participation of a lot of very talented people (including you), but we 
all have a finite amount of time.   So I think CFRG needs to figure out 
what topics to prioritize, and get people to volunteer as authors and 
reviewers (which could include implementers, in the case of specifications).

There clearly is interest, within IETF and CFRG, regarding ECC 
alternatives.  It would be good to have a discussion on what sort of 
RFCs would be most useful, which could include security analysis or 
separate recommendations as well as specifications.   Speaking as an RG 
member, not a chair, I personally like the idea of an RFC describing 
Montgomery or Edwards curves that provides the same sort of information 
as RFC6090: definitions, implementation guidance, references on 
security, and so forth.

I hope that this makes sense - I took a detailed question and gave a 
broad answer :-)