Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/01/2014 16:32, Simon Josefsson wrote:

> [draft-josefsson-tls-curve25519-03]

Strong interest here. Curve25519 in particular has extremely fast,
public-domain constant-time implementations compared to, say,
secp256r1, with better security, and a less clouded origin.

Better forward security at a very fast speed? Yes please!

1. Representation - Endian

I had thought that I might point out that all the existing routines in
the wild use little-endian representations and so that might be a good
reason to prefer that, so the routines can be used directly to
accelerate rollout.

But on reflection, pretty much everything else in internet standards
goes big-endian, so there's consistency there, and an endian swap
isn't exactly a big deal. No objection.

2. Monty & Eddie

You list both Montgomery and Edwards curves in that list. I suggest
just listing the Montgomery curves (Curve25519, M383 and M511) for
this use, as these are the forms that are the very natural choices for
ECDHE, with the handy x-coordinate-only feature.

Edwards forms (Curve1174, E382, Curve3617, E521 in their natural
states) are more eminently suitable for other uses like authentication
(although definitely should not be used with ECDSA, and note EdDSA as
specified is actually closely tied to Ed25519 - really we should
specify a new derivative, which we should really get on with).

You can also convert between the representations (e.g. Ed25519 is the
twisted Edwards isomorphism of Curve25519). The ones which are
naturally specified in Montgomery form have handy basepoints in that form.

I'd suggest putting Curve25519 as a MUST to implement, and M383 and
M511 as a MAY.

3. Security Considerations: Implementation

Thoughtful. Do we need to directly specify that implementations MUST
avoid side-channel attacks, because otherwise they might be tempted to
implement them in a way that isn't constant-time?

(There's a typo in that section, by the way; "22519".)

4. Other uses

I think other uses of these curves, which should definitely be
specified, should be specified in another draft (i.e. something like
EdDSA one, though it may not end up being exactly EdDSA).

We'll want OIDs for that. Can we get some for these "Chicago curves"?
I gather there's one suggested for Curve25519: could Mr Gutmann
perhaps please provide us with some for all of the others? (We could
put them in the eventual CFRG informational RFC for posterity, then.)

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJS0YR1AAoJEOyEjtkWi2t6z3AP/jwvsUwcPawNSsT8hIxJkLg+
tj8kUMeyRpxv2gqzGudycxAwi9WVV9LD9ml7Up9dfRQfxbkIr1lj6Y3Xbf/UbMXe
ENw9rvTz15p9p7fZJN8vb0Ab19xGptzwBtMl3sMeOy4eCeATLq0smpPqfgLNwl6m
FHcP8Vx4zrvvs1OKPlgUEEwv6l6F6A5P4OytW48WmIVGMr4ud34JPJAv4OdscvXD
8jtythP1b2Pvr+j+03LP9b0beV74YgwlqCpyQtTmLF/W7WtmW1xdBs0mKP94bB/K
9AGH86pUuBi/fBfn9lUDBkaETx6EnN8r9Mzat96o9gL2DB+s8ML0+1ckZkORzISb
VDVGxv5bZLBuW9zVlelsfAJO0az7DCaS5WKk3pKvhO9uT1R66EWpWwHJiJd4+TFB
H85Ko+tU65xBwh5Er/uiLwCAq205D9GFxd+MZUfNOWIDQ8/8rx+OrAImDJbkOxwr
+yOs7c1jbXlDaI9aA3j894d3ZDAFG5wal8m+gYRJumLfN8ufwr0bYYLpJy+DeFwN
i1Ic+Jj8b513/YxKNdJNZcK6RtL7taDAv8jl7Yiym2ze8PMZWJtsqyL06KCeDt0C
9ZzGQGV/AoDiJ1xktFwZ1YGPcTavqq9167l/r9JP0v4riA1O1Xnr9LaVBs8Z2++D
o2g0CcBzXK0AhWfLqfbC
=nhGq
-----END PGP SIGNATURE-----