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

David McGrew <mcgrew@cisco.com> Thu, 16 January 2014 01:20 UTC

Return-Path: <mcgrew@cisco.com>
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 D40A61AE47C for <cfrg@ietfa.amsl.com>; Wed, 15 Jan 2014 17:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlCEJinFRF1I for <cfrg@ietfa.amsl.com>; Wed, 15 Jan 2014 17:19:59 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id C2E531AE43E for <cfrg@irtf.org>; Wed, 15 Jan 2014 17:19:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: AiIFAFAz11KtJXHB/2dsb2JhbABZgwuEDLgJgREWdIIlAQEBAwEjDwEFOwUBBQsLGAICBRYLAgIJAwIBAgFFBg0BBQICF4dhCKdZm2kXgSmNVgeCb4FIAQOJR45ZhkWLUINLHoEuJA
X-IronPort-AV: E=Sophos;i="4.95,666,1384300800"; d="scan'208";a="13175972"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-6.cisco.com with ESMTP; 16 Jan 2014 01:19:47 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8914.cisco.com [10.117.10.229]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0G1JkpK018080; Thu, 16 Jan 2014 01:19:47 GMT
Message-ID: <52D733B2.8020603@cisco.com>
Date: Wed, 15 Jan 2014 20:19:46 -0500
From: David McGrew <mcgrew@cisco.com>
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 <watsonbladd@gmail.com>
References: <CACsn0cn+83gSD8NuYk4KTVL_11ydi+WJbDLc5BAj7dBH13HXhw@mail.gmail.com> <52D2BAE5.1010902@elzevir.fr> <CACsn0cmmtYCDiwDJL3bOgGaWv6HQn0tOrHxWtTuKndioE_c4Qw@mail.gmail.com>
In-Reply-To: <CACsn0cmmtYCDiwDJL3bOgGaWv6HQn0tOrHxWtTuKndioE_c4Qw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Editing work on github of draft-ladd-safecurves
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, 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 <mpg@elzevir.fr> 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.

David


> 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
>
>
>