[Cfrg] Maturity vs. Novelty consensus documentation requirement (was:Re: Bad and Rigid Curve (Rigid << NUMS))

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 07 August 2014 20:32 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 DDBE61A0314 for <cfrg@ietfa.amsl.com>; Thu, 7 Aug 2014 13:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9ZqZeG8q7G_D for <cfrg@ietfa.amsl.com>; Thu, 7 Aug 2014 13:32:31 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie []) by ietfa.amsl.com (Postfix) with ESMTP id E30FA1A00D7 for <cfrg@irtf.org>; Thu, 7 Aug 2014 13:32:30 -0700 (PDT)
Received: from localhost (localhost []) by mercury.scss.tcd.ie (Postfix) with ESMTP id 13D1EBE8A for <cfrg@irtf.org>; Thu, 7 Aug 2014 21:32:30 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([]) by localhost (mercury.scss.tcd.ie []) (amavisd-new, port 10024) with ESMTP id gyO0U48rm5t5 for <cfrg@irtf.org>; Thu, 7 Aug 2014 21:32:29 +0100 (IST)
Received: from [] (unknown []) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E7DC2BE16 for <cfrg@irtf.org>; Thu, 7 Aug 2014 21:32:28 +0100 (IST)
Message-ID: <53E3E25C.8090408@cs.tcd.ie>
Date: Thu, 07 Aug 2014 21:32:28 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <810C31990B57ED40B2062BA10D43FBF5CC9264@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CC9264@XMB116CNC.rim.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/HE10b0XBkNPkcLW6RbM8k849yyU
Subject: [Cfrg] Maturity vs. Novelty consensus documentation requirement (was:Re: Bad and Rigid Curve (Rigid << NUMS))
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: Thu, 07 Aug 2014 20:32:33 -0000

Speaking as an interested non-cryptographer... but with
no hats as well, so a bare headed non-cryptographer:-)

On 07/08/14 18:31, Dan Brown wrote:
> Rather, we should be placing
> much more emphasis on the maturity of cryptanalysis.

As I mentioned in Toronto, I think it'd be great if CFRG
documented its consensus on this point too. That is, I'd
like to pose a requirement that CFRG explicitly attempt
to reach consensus on the value or non-value of selecting
curves that have been known for some time and that that
be documented. (Not in 100's of pages of formulae mind
you, a paragraph or two of consensus text should be all
that's needed, if such a consensus exists.)

For new algorithms, I think being new is a very obvious
downside, but its less clear to me if that also applies
to some or all newish curves. And I think there will be
other IETF folk who could also do with some documentation
of that aspect too.

For example, if CFRG conclude that this is a non-issue,
and decided to generate some brand new curve(s), then
documenting the consensus that that is ok would really be
needed I think, since the concern about novelty would be
raised later on for sure.

Equally, if CFRG think a bit of aging in oak is valuable
then saying that would be good. Or, if there's no consensus
on this point (which I could imagine given how it might put
a finger on the scales) then some documentation of the
arguments would be useful.