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

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Cfrg [mailto:[e-mail]] On Behalf Of Daniel Kahn Gillmor
> Sent: Thursday, January 29, 2015 11:30 AM
> To: [e-mail]
> Subject: Re: [Cfrg] big-endian short-Weierstrass please
> 
> On Wed 2015-01-28 18:38:49 -0500, Blumenthal, Uri - 0558 - MITLL wrote:
> > The problem is - reasonably-vetted by who? NIST? DJB? Yourself? All of
> > the above?
> 
> If this lengthy process we're involved in doesn't turn out to be reasonable
> vetting by a multistakeholder group, i'll be sorely disappointed.
> 
> > 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.
> 
> This is different from the PGP Web of Trust.  If i'm communicating with a new
> peer using TLS, and they want to use MagicCurveX that i've never seen before,
> my TLS client is not going to be able to evaluate it properly, certainly not before
> the TLS handshake expires.
> 
> Anyone can of course decide what curves are worth using, and can apply their
> own analysis with their peers to come to that decision.  But if you're
> communicating with the arbitrary outside world, there needs to be some
> broader consensus about which curves to commonly use.

[DB] Isn't TLS 1.3 proposing a DH group negotiation mechanism, where peers could configure their supported set of (EC)DHE group, then at run-time find something in the intersection of their supported curves?  Having an option to fully specify a custom curve in this mix is not requiring any peers to support MagicCurveX.  

> 
> The act of naming and identifying the curve doesn't mean it's good, of course;
> We have named codepoints for curves insufficient for modern cryptanalysis, like
> sect163k1.  But you're right, people should be able to use curves internally that
> no one else has to weigh in on.
> fortunately, we can already do that (at least in TLS); we have a range of the
> codepoints set aside for private use (RFC 4492):
> 
>   Values 0xFE00 through 0xFEFF are reserved for private use.

[DB] Wouldn't users of these private values have to then customize their software this?  Well, I guess TLS would work for that.  So, it seems that the advantage of specified curves, is that if a trustworthy WebSiteABC TLS server, elects to use MagicCurveX, then anonymous TLS clients could connect to WebSiteABC, relying on the current trust of the WebSiteABC, and their own software.