Re: [TLS] Curve25519 in TLS

[Nico Williams <[e-mail]>]

On Thu, Oct 17, 2013 at 1:30 PM, Martin Rex <[e-mail]> wrote:
> This should probably be a variable length vector so that the
> format can be reused beyond curve25519 for similar curves with
> longer keys (is curve3617 such a thing?)

Yes (and yes, at least it exists as a curve specification in
safecurves.cr.yp.to; dunno if code exists).  (Ditto Curve1174.)

<aside>
If the choice is between

   sequence {curve ID, variable-length octet string}

   extensible choice with curve ID as discriminant and the value type
is a fixed-sized octet string of size given by the curve ID

   sequence {curve ID, octet string of size given by curve ID}

which is best?

The first two are commonplace and easy to implement; the first being
the easiest to implement.  The last is akin to ASN.1's IOS -- too
complex, no one will bother as no one has bothered.

So that's two choices, the first one being historically easier to implement.
</aside>

> Extending plus subsetting rfc4492, so that PDUs and code points
> for ECDH cipher suites can be shared between curve25519 and other
> ECC curves, seems appropriate and acceptable.

Yes.

> But I would highly appreciate if the generic bloat, brittleness and
> timing-sensitive ECC math of regular rfc4492 can be avoided as much
> as possible.  So a new, simplified/specialized ECPoint format that
> is mandatory for use with curve25519 and relatives, would help a lot.

Agreed.

Nico
--