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

[Watson Ladd <[e-mail]>]

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.

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



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin