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

From: Watson Ladd <[email-masked]>
Date: Sat, 11 Jan 2014 15:28:29 -0800

Dear all,
To avoid clogging up the IETF with endless revisions, I've decided to
do the wordsmithing on github. Emails to me are still excellent ways
of communicating issues, but for those inclined to do typo work and
other valuable (and underappreciated) editing efforts, feel free to
examine an up-to-date copy at github.com/wbl/safecurvesdraft.

Quite a few people have argued that I need to explain the
double-and-add algorithm, even though it is standard. Then again I
have no idea what sort of implementation details are generally
considered necessary in a draft, especially when they are completely
unnecessary to specify the "what" of the behavior. This seems to me to
be the biggest issue of contention with regards to the draft: some
people want something ala RFC 6090, while I want to avoid massive
bloat with implementation details that anyone implementing this draft
probably knows anyway. This isn't a strongly principled stand on my
part, but I would like to see this move through swiftly.

Sincerely,
Watson Ladd

---

From: Watson Ladd <[email-masked]>
Date: Sun, 12 Jan 2014 08:18:48 -0800

On Sun, Jan 12, 2014 at 7:55 AM, Manuel Pégourié-Gonnard <[email-masked]> wrote:
> Dear Watson
>
> [off-list]
>
> On 12/01/2014 00:28, Watson Ladd wrote:
>> 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

---

From: David McGrew <[email-masked]>
Date: Wed, 15 Jan 2014 20:19:42 -0500

Hi Watson,

let me ask that you track the contributions made to the draft and make 
sure that the contributors understand that we need for them to grant 
rights of use to their text to the IETF Trust (see the section "Rights 
Granted by Contributors to the IETF Trust" in RFC 5378).

If the contributors are just fixing typos, then this is unlikely to be a 
big deal.   But copyright is an important issue for the IETF, and I just 
want to make sure that contributions are tracked, so that we can head 
off any potential future concerns that might prevent RFC publication.

thanks,

David

On 01/11/2014 06:28 PM, Watson Ladd wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: David McGrew <[email-masked]>
Date: Wed, 15 Jan 2014 20:19:46 -0500

Hi Watson,

> 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

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Jan 2014 08:49:40 +0000

Hi,

> examine an up-to-date copy at github.com/wbl/safecurvesdraft.

we need to be careful here. When people post suggestions to this mailing list, they know they are making contributions to the IRTF and IETF, and so they are obligated to make IPR disclosures, when applicable. (See http://irtf.org/ipr)

When you incorporate text or ideas that were emailed to you personally, those private emails to you are NOT "contributions to the IETF/IRTF", because they are not sent to one of our lists. That means people need not disclose IPR, and when you (in good faith) incorporate their ideas or text, undisclosed IPR may end up in your document.

It's therefore safest to only incorporate ideas and text that were sent on the public list.

(That also lets everyone know who made suggestions for edits. In light of the long recent discussion on how we can prevent bad actors from subverting our standards, having all of this on the list increases transparency, which is in the end our best defense.)

Lars

PS: This of course applies to all RG work, not only your draft in particular.

---

From: David McGrew <[email-masked]>
Date: Thu, 16 Jan 2014 08:18:27 -0500

> (That also lets everyone know who made suggestions for edits. In light of the long recent discussion on how we can prevent bad actors from subverting our standards, having all of this on the list i…

Good points about transparency and IPR.   Thanks Lars.

David

---

From: Watson Ladd <[email-masked]>
Date: Thu, 16 Jan 2014 07:29:02 -0800

On Thu, Jan 16, 2014 at 5:18 AM, David McGrew <[email-masked]> wrote:
> we need to be careful here. When people post suggestions to this mailing
> list, they know they are making contributions to the IRTF and IETF, and so
> they are obligated to make IPR disclosures, when applicable. (See
> http://irtf.org/ipr)
>
> When you incorporate text or ideas that were emailed to you personally,
> those private emails to you are NOT "contributions to the IETF/IRTF",
> because they are not sent to one of our lists. That means people need not
> disclose IPR, and when you (in good faith) incorporate their ideas or text,
> undisclosed IPR may end up in your document.

The only IPR issue is with patents, and I'm not incorporating new implementation
methods.

With regards to copyright, so far it's been typos. I'll ask people to
agree to license
their contributions under the terms of BCP whatever it is before
incorporating anything
more substantive.

> (That also lets everyone know who made suggestions for edits. In light of
> the long recent discussion on how we can prevent bad actors from subverting
> our standards, having all of this on the list increases transparency, which
> is in the end our best defense.)

If your assessment of the draft depends on whether or not I work for the NSA,
you are making a terrible mistake. At some point there will be a text
freeze, for
formal last call consideration. At that point, I hope you pretend
every single word
was written by an unholy consortium of everyone who ever wants to subvert
a standard. Read it like a lawyer reading a deal with the devil.
That suspicion and its discussion on the list is the best defense
against mistakes and errors of all kinds.

Sincerely,
Watson Ladd

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Jan 2014 16:23:03 +0000

Hi,

> The only IPR issue is with patents, and I'm not incorporating new implementation

that's great, but not really sufficient.

What matters is that others, who may actually believe that they hold IPR on something in your draft - whether that claim is valid or not (or sensible or not) - are put under an obligation to disclose this belief. That obligation only exists if such contributions are made to the IETF and IRTF. It does not exist when they make private comments to you personally.

The IETF process is carefully designed to bring such IPR claims into the open. That's valuable, and I'd hence recommending following it.

> their contributions under the terms of BCP whatever it is before

The IETF and IRTF already *have* a process that handles this automatically when such contributions are made on an IETF or IRTF mailing list, see BCP78. Why create more work for everyone involved?

> against mistakes and errors of all kinds.

I fully agree. However, information is lost when you incorporate ideas sent by third parties without being extremely diligent in acknowledging where they came from in the document. If you collect feedback on this list, everyone can follow who made what suggestion while the document is being worked on.

And then at the end, we still apply the "read it like a lawyer reading a deal with the devil"-approach.

Lars

---

From: Watson Ladd <[email-masked]>
Date: Thu, 16 Jan 2014 08:24:57 -0800

> And then at the end, we still apply the "read it like a lawyer reading a deal with the devil"-approach.

Okay. I'll ask everyone who sends me comments to put them on the list
and tag them in the subject line so they can be easily ignored by
those
uninterested in typo fixes.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Jan 2014 16:29:05 +0000

> uninterested in typo fixes.

Great, thanks!

Lars