Re: [Cfrg] big-endian short-Weierstrass please

[Nico Williams <[e-mail]>]

On Wed, Jan 28, 2015 at 11:38:49PM +0000, Blumenthal, Uri - 0558 - MITLL wrote:
> On 1/28/15, 18:10 , "Nico Williams" <[e-mail]> wrote:
> >On Wed, Jan 28, 2015 at 05:30:28PM -0500, Daniel Kahn Gillmor wrote:
> >> On Wed 2015-01-28 16:23:27 -0500, Dan Brown wrote:
> >> > For example, RFC 4492 allows curves to be specified in Weierstrass
> >> > form, not just as named form.  I don't know if any TLS implementations
> >> > support the specified curve option, but if they do, then it would be
> >> > nice if the new implementations could talk to them, using the new
> >> > curves.
> >> 
> >> Over in the TLS WG, we're working on actively deprecating the custom
> >> curve selection mechanism and moving strictly toward pre-named curves
> >> (this is true for finite-field DH as well).  Custom curve and FFDHE
> >> group selection will be gone in TLS 1.3.
> >> 
> >>……
> >> 
> >> I don't think this is a particularly useful half-measure.  I'd rather
> >> see implementations pick up new, reasonably-vetted curves than try to
> >> muddle through supporting arbitrary curves provided by the peer.
> >
> >+1
> 
> The problem is - reasonably-vetted by who? NIST? DJB? Yourself? All of the
> above?

Besides the answers given already, this question is kinda strange.  Why
say "by whom"?  It's implied in "vetted" that the entities doing the
vetting are acceptable to the user.  And anyways, the question is not
relevant to Daniel K. G.'s point, which was: negotiate from sets of
known curves rather than negotiate arbitrary curves whose parameters get
sent to you by your peer.  If we do this then each curve can have its
own point format on the wire, with whatever endianness it wants.

(Mind you, point format could be yet another set of parameters to
negotiate, but why bother with so much complexity?)

Generalization often is nice, but here it would mean having to engage in
an expensive effort to write a pile of code that we wouldn't otherwise
need only for the sake of generalization.  I don't see a win there.

Dan B. doesn't need us to use a generic point encoding for all curves in
order for his preferred curves to be usable.  There is no advantage to
be had in using a generic point encoding here, and plenty of
disavantages (among them: more code, instant obsolescence of existing
implementations of curves we might end up approving of).  Please no.

> Attractiveness of the ability to select a custom curve is similar to that
> of PGP Web of Trust: you can make a choice for yourself, rather than being
> forced into what other experts (or “experts” :) decide for you.

Yes, you might trust your selection, but if your peers don't then you
lose.  The flip side is that if you want to talk to a peer that wants
you to use their curve, you might have to trust them, and how would you
know whether to trust them?  In a small network you could manage this,
and one generic point encoding will help you, but you could pick one
from a set of more than one.  And anyways, it'd be a small network --
why should the Internet community bend over backwards to make it easy
for you to pick your very own curves for use in your very own small
network?  There are still no advantages to be found in your proposition
for having one generic point format for all curves.

Outside your small network only pre-defined curves will work.  The
vetting is what we're doing now.  It doesn't have to happen only here,
and we needn't be the only vetters, but we don't need a single generic
point encoding to allow multiple vetters.

Nico
--