Re: [Cfrg] 40 bit loop and DragonFly

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 05 January 2014 10:34 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155881ADF8C for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 02:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 6t15opfbGohy for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 02:34:03 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA21ADF89 for <cfrg@irtf.org>; Sun, 5 Jan 2014 02:34:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70613BE74; Sun, 5 Jan 2014 10:33:54 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nyxPWyGxegc; Sun, 5 Jan 2014 10:33:53 +0000 (GMT)
Received: from [10.87.48.14] (unknown [86.44.71.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 03B8ABE6E; Sun, 5 Jan 2014 10:33:52 +0000 (GMT)
Message-ID: <52C93506.5070100@cs.tcd.ie>
Date: Sun, 05 Jan 2014 10:33:42 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Igoe, Kevin M." <kmigoe@nsa.gov>, "'cfrg@irtf.org'" <cfrg@irtf.org>
References: <3C4AAD4B5304AB44A6BA85173B4675CABA99F80C@MSMR-GH1-UEA03.corp.nsa.gov>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABA99F80C@MSMR-GH1-UEA03.corp.nsa.gov>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] 40 bit loop and DragonFly
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: Sun, 05 Jan 2014 10:34:07 -0000

Kevin,

On 01/05/2014 01:41 AM, Igoe, Kevin M. wrote:
> Potential IPR issues:
> Certicom has granted permission to the IETF to use the NIST curves, 
> and at least two of these, P256 and P384, have p = 3 mod 4.  

I'm not sure what exactly you mean there. From my POV, Certicom
have declared [1] that they consider that some of their IPR is somehow
required in order to implement the most excellent RFC 6090 [2] which
only references things published at least a year before Certicom's
first filing. I also seem to recall that some of their IPR
declarations do include restrictions on things like CAs issuing
certs.

So "granted permission" is not quite so clear. At least not
without either being a lawyer, or having whatever time machine
Certicom's lawyers seem to possess. I doubt we'll clarify the
IPR situation around ECC here, nor around PAKEs unfortunately.

But I think we can conclude that the Dragonfly goal of designing
around existing IPR remains a valid design goal. Whether or not
Dan has succeeded in that is another matter, participants who
care about IPR need to evaluate that for themselves.

S.

[1]
https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6090
[2] http://tools.ietf.org/html/rfc6090

> Not 
> being a patent lawyer, I have no idea what impact the Certicom patents 
> have on the use of newer families of curves, such as Edwards curves.  
> RFC 6090 outlines elliptic curve technology which predates the Certicom
> patents.