Re: [TLS] Curve25519 in TLS

[Manuel Pégourié-Gonnard <[e-mail]>]

On 16/10/2013 08:42, Martin Rex wrote:
> Make it work completely _without_ rfc4492 bloat,
> and similar to DH instead, defining new KeyExchange Methods
> and seperate ciphersuites for it.
> 
If we want to cover all existing key exchanges and ciphersuites, this would mean
defining four new key exchanges (ECDH25519-PSK,RSA,ECDSA,anon), and 52 new
ciphersuites currently. And then duplicating every ECDHE-based ciphersuite
defined in the future. And if at some point, a new Montgomery or Edwards curve
is proposed (maybe the recent curve3617), duplicating all that again.

That's quite a lot of trouble: what specific problem would it solve? What
exactly do you mean by RFC 4492 "bloat", and in which specific way defining new
key exchanges would make it lighter? As an implementer, I don't feel like adding
new key exchanges for Curve25519 would make my life any easier, as it would come
*in addition* to RFC 4492 support.

Anyway, I believe that cryptographic parameters agility is a highly desirable
property of a protocol like TLS, and RFC 4492 provide that, better than
specialised key exchanges supporting only one curve. If that solution had been
adopted in early 2006, the only one curve would probably have been a NIST curve
(curve25519 was very new at the time, while NIST curves had been around for
years), and you wouldn't be very happy now, I guess.

I hope my first post didn't give the wrong impression: I don't think the
framework from RFC 4492 is a misfit for the Curve25519 ECDH function, the only
real point of friction is the encoding of the public keys. The other remarks I
made are merely things I'd like to see clarified in the draft, and information
that seemed relevant to me to discuss the public key format.

Manuel.