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

[David McGrew <[e-mail]>]

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 <[e-mail]> 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
>
>
>