Re: [Cfrg] Task looming over the CFRG

Michael Hamburg <mike@shiftleft.org> Mon, 05 May 2014 18:25 UTC

Return-Path: <mike@shiftleft.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 ADE481A0406 for <cfrg@ietfa.amsl.com>; Mon, 5 May 2014 11:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.557
X-Spam-Level: *
X-Spam-Status: No, score=1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] 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 ig2fDHFQRiiR for <cfrg@ietfa.amsl.com>; Mon, 5 May 2014 11:25:10 -0700 (PDT)
Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) by ietfa.amsl.com (Postfix) with ESMTP id 00BB01A0409 for <cfrg@irtf.org>; Mon, 5 May 2014 11:25:09 -0700 (PDT)
Received: from [10.184.148.249] (w035.z205158021.lax-ca.dsl.cnc.net [205.158.21.35]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 8DA103AA3F; Mon, 5 May 2014 11:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1399314176; bh=bKKJiuGYKen/VcWY64bE4RHVLbveYiLjQOBOTboQcrA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=T1Tq6vupmNqr8Afg7IZLAUwzcSaSOZILpValicvszKLr09YsDfqZsNGDxeFB+MMQW YjG/H/BIhqKhZXaF+3OQOi+gePwfshAXi6Wm6pLXJyuqZDFf2apCbtRtEx8U1sHvyc 0tjENmuOf1NsdmA7StcVl6pncFoexwMO4B2KPSss=
Content-Type: multipart/alternative; boundary="Apple-Mail=_B8138695-AA74-4AC9-B7D2-69BA7D5D2D0B"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Hamburg <mike@shiftleft.org>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABAA4022F@MSMR-GH1-UEA03.corp.nsa.gov>
Date: Mon, 05 May 2014 11:25:05 -0700
Message-Id: <E98B42D5-610C-4532-B765-5819A35A456C@shiftleft.org>
References: <3C4AAD4B5304AB44A6BA85173B4675CABAA4022F@MSMR-GH1-UEA03.corp.nsa.gov>
To: "Igoe, Kevin M." <kmigoe@nsa.gov>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BkFuy40glZGK38KZxfmSsiEa1ag
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Task looming over the CFRG
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: Mon, 05 May 2014 18:25:11 -0000

Hi Kevin,

As the designer of an ECC system which is aimed at 224-ish-bit security, I’m curious: is it a firm requirement that the curves be set at 128, 192 and 256 bits?  Or was there consensus in the meeting that the curves should be set at these security levels?  Patrick Longa aimed his talk at these security levels, but I don’t recall this being stated as a requirement.

Cheers,
— Mike


On May 5, 2014, at 10:58 AM, Igoe, Kevin M. <kmigoe@nsa.gov> wrote:

> As most the folks who read this list have noticed, a virtual interim meeting of the CFRG
> was held on Tues 29 April to discuss the way forward for elliptic curve cryptography
> in the IETF.  This was driven by an earnest plea from the TLS WG for firm guidance from 
> the CGRG on the selection of elliptic curves for use in TLS.  They need an answer before 
> the Toronto IETF meeting in late July.  TLS needs curves for several levels of security (128, 
> 192 and 256), suitable for use in both key agreement and in digital signatures.
>  
> The consensus of the attendees was that it would be best for TLS to have a single
> “mandatory to implement” curve for each of the three security levels.
>  
> Though the attendees were reluctant to make a formal commitment, there
> was clearly a great deal of support for the Montgomery curve curve25519 (FYI, the 
> 25519 refers to the fact that arithmetic is done modulo the prime 2**255 – 19 ).
>  
> curve25519 only fills one of the three required security levels.  We still need
> curves of size near 384 bits and 512 bits.
>  
> NIST curves: I doubt TLS will be willing to revisit the question of elliptic curves once the 
> CFRG has made their recommendation.  Another option to consider is advising TLS to
> use of the NIST curves in the short term, buying time for the CFRG to do an unrushed 
> exploration of the alternatives, drawing academia and other standards bodies into the 
> discussion.
>  
> P.S.  It has been suggested that the CFRG hold a session at the Crypto conference in
> Santa Barbara in an effort to draw in more participation from the academic community.
> No guarantees we can pull this off, but it is worth the attempt. Thoughts? Volunteers?
>  
> P.P.S. We need to start lining up speakers for the CFRG session at IETF-90 (Toronto).
>  
>  
> ----------------+--------------------------------------------------
> Kevin M. Igoe   | "We can't solve problems by using the same kind
> kmigoe@nsa.gov  | of thinking we used when we created them."
>                 |              - Albert Einstein -
> ----------------+--------------------------------------------------
>  
>  
>  
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg