Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 14, 2015 at 05:23:44PM +0200, Simon Josefsson wrote:
> Hubert Kario <[e-mail]> writes:
> 
> > So unless the PKIX and TLS parts are defined at the same time, in the same 
> > document, we definitely need to keep them apart.
> 
> It is conceivable to reuse the NamedCurve values for TLS authentication
> without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work.
> 
> Compare how we "reuse" the ECDHE ciphersuite values to refer to
> Curve25519 (instead of defining new ciphersuites for Curve25519), and
> how we are "reusing" the "uncompressed" code point to refer to
> Curve25519-compressed code points (instead of defining new
> ECPointFormat).

Well, allowing curve to set point format isn't much of a stretch (and in
fact, TLS 1.3 as of currently requires this).

If one does only "uncompressed" format, all current ECDHE curves work
as a triple:
- Keybytes: How many bytes of private key it wants.
- Generate: Take in private key, output public key.
- Agree: Take in private key and peer public key, output premaster secret
  (or ES/SS in TLS 1.3).

(Instantiating that for both uncompressed NIST P-256 and Curve25519 is
left as an simple excercise).

> Allocating new values when that creates additional costs and no improved
> clarity seems wasteful to me.  This approach is what people have
> suggested for most other allocations here, so I prefer to stick to that
> philosophy unless it is clear that there is consensus for something
> else.  What do others think?

Well, that would imply that implementation that supports Curve25519 and/
or Curve448 sigs has to also do ECDHE with exactly those curves. And
conversely, anything that does both Curve25519 and Curve448 ECDHE and
does signatures with either has to do signatures with both.

In implementation, signatures are quite a bit more complicated than
ECDHE.


-Ilari