Subject: [Cfrg] Brazil Curves -> Re: Safecurves draft redux

From: Paul Lambert <[email-masked]>
Date: Mon, 20 Jan 2014 12:11:49 -0800

>
>The naming issue is fine: we can say "the safecurve Mxxx has been
>found to be unsafe" without risk of being misunderstood. If there is
>consensus that we should call the IANA registry something else, say
>"Chicago curves", I'm not opposed to it.

More of the curves seem appear to have come from Brazil (not necessarily
the movie) than Chicago.

There was a thread on clear naming conventions that has some consensus
that did not add confusion by creating cute names.  Could we please
proceed with a consensus based draft.

I also believe we are rushing too fast on the Œtrimming¹ before we have
clearly identified and listed the attributes of the curves we have under
recommend.  A draft list the alternates and attributes seems essential.
Consensus might then be possible when we can have are more coherent and
documented review process.

Also, there is value in having strong recommendations for a few curves
used for identity/authentication.  There is also value in describing
alternatives for new protocols that might wish to have some crypto
diversity.  Documented a larger set with well described properties and
possible applications would meet both requirements.

Paul

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Jan 2014 14:28:04 -0800

> proceed with a consensus based draft.

Naming them E or M then prime description would work. We would also need a
T. So far I've resisted renaming from the SAFECURVES names, but that
will change since
we need to invent some.

As for naming the whole set, that's where Chicago comes in. Brainpool
is certainly not
a cute name, but I doubt the mental images were in the naming process.

We aren't even at a point where I have something I would sent to Last
Call. I have
some edits to make (see TE25519 discussion where I screwed it up),
and with the start
of the semester haven't had time to do this yet.

> documented review process.

Well, I haven't trimmed anything yet: I just want to have discussion
about how many we should recommend.
As for listing the attributes and identifying them, I think the draft
makes it pretty clear, even it is current state, what
these curves are. Perhaps we need to make more clear that most
implementations of ECC get it wrong. (Even AGL and
I punted when making constant time P256 implementations: we return
errors in some cases where we shouldn't.)

> possible applications would meet both requirements.

All curves avoiding certain known badnesses are the same from a
security standpoint.
They aren't from an efficiency standpoint. if a new protocol wants
diversity, it should avoid
ECC entirely.

As for possible applications, I'm really not sure what we're looking
at here. Given a curve you can get
Schnorr signatures and ECDH on it. That will be in a different
draft/is bog-standard cryptography.

There is a PAKE idea for the new curves that is being developed, but
it still needs to get drafted.

Sincerely,
Watson Ladd

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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 20 Jan 2014 14:59:36 -0800 (PST)

> of the semester haven't had time to do this yet.

  You seem to think that the next step is Last Call. Please peruse the
RFC database and note the revision of the last draft prior to publication
as an RFC. You'll find many that have double-digit revisions. And you'll
note that very few have an -01 revision.

  It is very helpful in this consensus-based development process to
produce a draft for everyone to read that incorporates a slew of
comments you received. That way we can see how it reads after the
comments were resolved and possibly suggest how to further improve
it, resulting in another version. Holding on to a draft until you personally
feel that it is ready for Last Call is likely to blow up in your face.

  If you want this published in an I{E|R}TF stream then please follow
the process for working on a draft. Github is not an appropriate
substitute.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Jan 2014 09:27:56 +0200

> the process for working on a draft. Github is not an appropriate

A substitute - no, but GitHub can be a useful tool when multiple people 
contribute text. As an example, the http2 draft is being edited in 
GitHub with the various contributors making suggestions ("pull 
requests") there. The discussion is mostly done on the mailing list, but 
GitHub is far from useless.

Yoav