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

[Watson Ladd <[e-mail]>]

On Jan 29, 2015 8:50 AM, "Dan Brown" <[e-mail]> wrote:
>
>
> > -----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.

This is not how TLS negotiation works: the client offers and the server
picks. Due to vulnerabilities in all versions of TLS (still unfixed) one
always has to check the offered parameters for correctness.

That's on top of the fact that people don't want to use Curve25519 because
it's Curve25519. They want to use it because the design choices support
high speed secure implementations.

It's possible to get the existing extension to do this, but only if we have
a magic list of what to offer, and do all sorts of contortions in our
calculations. Much easier to negotiate an extension as the TLS WG
extensively discussed.

Sincerely,
Watson Ladd

>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg
>