[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [173.37.142.88]) 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-Anti-Spam-Result: AkEFABek1VKtJXG9/2dsb2JhbABagkdEOLtCgRcWdIIlAQEBBC1LARAZCgkWDwkDAgECAUUGDQEHAogADcNtF44lCgcBUAeENwSJRY5ZgTCFFYtQgW+BXB6BLAkX
X-IronPort-AV: E=Sophos; i="4.95,659,1384300800"; d="scan'208,217"; a="12828260"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 14 Jan 2014 20:56:38 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8914.cisco.com [10.117.10.229]) 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 :-) regards, David
- [Cfrg] [CFRG] Safecurves v Brainpool / Rigid v Ps… Dan Brown
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Watson Ladd
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Dan Brown
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Alyssa Rowan
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Watson Ladd
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Michael Hamburg
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Paul Lambert
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Watson Ladd
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Paul Lambert
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Manuel Pégourié-Gonnard
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Dan Brown
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Igoe, Kevin M.
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Mike Hamburg
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Dan Brown
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … David McGrew
- [Cfrg] publishing drafts (was: Re: [CFRG] Safecur… David McGrew
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Alyssa Rowan
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Paul Lambert
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Watson Ladd
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … David McGrew
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Watson Ladd
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Igoe, Kevin M.
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Dan Brown
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Manuel Pégourié-Gonnard
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … David McGrew
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … Johannes Merkle
- [Cfrg] NUMs/rigidity security (Re: [CFRG] Safecur… Adam Back
- Re: [Cfrg] NUMs/rigidity security (Re: [CFRG] Saf… David McGrew
- Re: [Cfrg] [CFRG] Safecurves v Brainpool / Rigid … David McGrew
- Re: [Cfrg] NUMs/rigidity security (Re: [CFRG] Saf… Adam Back