Re: [Cfrg] revised requirements for new curves

Damien Miller <djm@mindrot.org> Thu, 11 September 2014 07:35 UTC

Return-Path: <djm@mindrot.org>
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 D0FC61A6F4C for <cfrg@ietfa.amsl.com>; Thu, 11 Sep 2014 00:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 uGs1qYF0otwW for <cfrg@ietfa.amsl.com>; Thu, 11 Sep 2014 00:35:22 -0700 (PDT)
Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id CBF021A872E for <cfrg@irtf.org>; Thu, 11 Sep 2014 00:35:21 -0700 (PDT)
Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id s8B7ZJN8043946; Thu, 11 Sep 2014 17:35:20 +1000
Received: from mailhub.eait.uq.edu.au (taxus.eait.uq.edu.au [130.102.79.56]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id s8B7ZJ0E002888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Sep 2014 17:35:19 +1000
Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.14.6/8.14.6) with ESMTP id s8B7ZI8W003200; Thu, 11 Sep 2014 17:35:18 +1000 (EST)
Received: by natsu.mindrot.org (Postfix, from userid 1000) id 8D635A4F32; Thu, 11 Sep 2014 17:35:18 +1000 (EST)
Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 83F5EA4F31; Thu, 11 Sep 2014 17:35:18 +1000 (EST)
Date: Thu, 11 Sep 2014 17:35:18 +1000 (EST)
From: Damien Miller <djm@mindrot.org>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
In-Reply-To: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk>
Message-ID: <alpine.BSO.2.11.1409111641470.8744@natsu.mindrot.org>
References: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk>
User-Agent: Alpine 2.11 (BSO 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub
X-Scanned-By: MIMEDefang 2.73 on 130.102.79.56
X-UQ-FilterTime: 1410420920
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/H2XcTiDUGBH9ownv9RFnldAGkL4
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] revised requirements for new curves
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, 11 Sep 2014 07:35:26 -0000

On Mon, 8 Sep 2014, Paterson, Kenny wrote:

> Dear All,
> 
> After much deliberation, I've developed a set of requirements that I
> believe fairly reflect the discussions we've had as a community on the
> CFRG list, and at IETF 89, during the CFRG interim meeting and at IETF 90.

Thanks for compiling this and sorry for barging in late in the process.

> SE6. Required: the selected curves should provide levels of security that
> match to a good approximation 128-bit, 192-bit and 256-bit security
> levels, as these levels are currently commonly understood in the wider
> security community. [NC]

Speaking for OpenSSH, I don't see much point in a 192-bit "security level"
curve.

It's difficult to imagine a scenario where a 192-bit SL curve provides
something that the other don't. For the rest of the time, it's just code
and complexity that everyone has to carry that will be rarely used, and
therefore more likely to be wrong.

Perhaps consider splitting this into three requirements, one for each of
the "security levels"?

> Interoperability
> 
> IN2. Desired: usable with minimal changes to existing IETF RFCs for CMS,
> SSH, IKE, IKEv2, Kerberos PKINIT. [RC]

It would help if you defined what you meant by existing RFCs here. Do you
mean the overarching transport protocol definitions (RFC4253 in the case
of SSH) or the RFCs that define DH methods specifically (RFC5656 for SSH)?
latter for better curves/encodings.

-d