Re: [Cfrg] Editing work on github of draft-ladd-safecurves

David McGrew <> Thu, 16 January 2014 01:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D40A61AE47C for <>; Wed, 15 Jan 2014 17:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dlCEJinFRF1I for <>; Wed, 15 Jan 2014 17:19:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C2E531AE43E for <>; Wed, 15 Jan 2014 17:19:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4215; q=dns/txt; s=iport; t=1389835188; x=1391044788; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=e1VZiNczA1REdV82THR6KV8N9VtPw2JCPG0UrzHvr7k=; b=QMpmvCC7kv1cDl0bUXU1bOp+pfmSXnhdJmAKlK7nCoCR9vqMgjJEfPkl ZqR4OZGo+mWpdFN8d7/k+rM6RjzKi7jr18vwepY0iRaMrg0sp1ei7M3Gt fdwoiGLSLP6JEB+jAiDRjHtSdVF8H1MvYtp1FjzUq6R3uKBCJzgglLI/L w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,666,1384300800"; d="scan'208";a="13175972"
Received: from ([]) by with ESMTP; 16 Jan 2014 01:19:47 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s0G1JkpK018080; Thu, 16 Jan 2014 01:19:47 GMT
Message-ID: <>
Date: Wed, 15 Jan 2014 20:19:46 -0500
From: David McGrew <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Watson Ladd <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [Cfrg] Editing work on github of draft-ladd-safecurves
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jan 2014 01:20:02 -0000

Hi Watson,

On 01/12/2014 11:18 AM, Watson Ladd wrote:
> On Sun, Jan 12, 2014 at 7:55 AM, Manuel Pégourié-Gonnard <> wrote:
>> Dear Watson
>> [off-list]
>> On 12/01/2014 00:28, Watson Ladd wrote:
>>> To avoid clogging up the IETF with endless revisions, I've decided to
>>> do the wordsmithing on github.
>> To be clear, I'm afraid wordsmithing isn't what the draft needs right now. I
>> understand your haste to see the curves adopted in IETF protocols, but I really
>> feel like pushing the draft isn't the best or even the quickest way forward.
>> Others on list have expressed concerns about its contents, mainly
>> 1. Security analysis and careful comparison with the other curves;
>> 2. Helping implementers actually get the implementation right;
>> which are important goals currently not covered by the draft.
> What sort of analysis do we need here? I think the claim that the DDH is hard
> and takes square root of curve time/space complexity, and also that these are
> resistant to certain twist attacks, is a sufficient analysis. A review
> of the relevant
> attack literature might be nice: but no one has asked for it until you did.
> Salesmanship of the curves could be useful, but would take far longer
> to write then
> the time I care to spend.

A good solution to the above problem, and one commonly used in the IETF, 
is to bring other co-authors aboard to help to achieve the work that 
they want to see get done.


> Feel free to contribute appropriate language: It will be mentioned in
> the Acknowledgements
> as "XYZ contributed section A.B.C".
>> Concerning point 2, you'll probably agree that one of the most prominent
>> benefits of the curves is that they're designed so that the probability of
>> implementers not screwing things up is higher than for other curves. I think if
>> we want to reap the full benefits of this, the document specifying these curves
>> should provide step-by-step guidance to implementers in a way they can actually
>> use (remember implementers don't all have a solid math background on the
>> relevant topics).
> The new version (on github) explains what double and add and the
> Montgomery ladder are, as well
> as containing explicit formulas for the curves. What more do you need
> to implement these?
>> Concerning point 1, as you probably have noticed, Eric Rescorla, chair of the
>> TLS group, has recently made it clear that the curves need a detailed  and
>> thoroughly documented security discussion representing consensus from the CFRG
>> and/or any other relevant part (SAAG) of the IETF to move forward in TLS. I
>> think he's right, and even if I didn't, it's probably a good idea to listen to
>> him anyway.
> What exactly could this discussion possibly consist of? "ECDH on each
> of the curves has complexity sqrt size of curve"
> The problem is that we know the attacks and the safeguards so well,
> that the validation is mechanized.
> What does he want that the safecurves site doesn't already have.
>> My opinion is, if you want your work on the draft to be effective, it would
>> probably be better to first clarify the goals with the rest of the RG (and/or
>> other interested WG) and only then work on the redaction, paying attention to
>> the stated goals.
> The goal is simple: describe these curves and their properties, in a manner that
> is unambiguous and usable in IETF protocols. It's the same as for the
> Brainpool draft,
> which you will note, does not contain the algorithms.
> If you have a better way to get these curves into use, feel free to
> help. But so far
> I've noticed nothing has been happening until I do it. Some people
> have been quite
> helpful with this.
>> Of course I'm not in any way in a better position than you to judge what the
>> best course of action is, so I won't be offended if you choose to disregard my
>> advice :) Maybe taking advice from other, more experienced, people in the IETF,
>> about how to best use your enthusiasm, knowledge and willingness to help, would
>> be a good idea.
>> Sincerely,
>> Manuel.
> Sincerely,
> Watson Ladd