Re: [TLS] Curve25519 in TLS

[Yoav Nir <[e-mail]>]

On Sep 12, 2013, at 3:51 PM, Rob Stradling <[e-mail]> wrote:

> On 11/09/13 18:12, Simon Josefsson wrote:
>> Rob Stradling <[e-mail]> writes:
>> 
>>> Simon, thanks for creating this draft.
>>> 
>>> draft-merkle-tls-brainpool-04 (on which you've based this new draft) says:
>>>    "While the ASN.1 object identifiers
>>>    defined in [RFC5639] already allow usage of the ECC Brainpool curves
>>>    for TLS (client or server) authentication through reference in X.509
>>>    certificates according to [RFC3279] and [RFC5480] , their negotiation
>>>    for key exchange according to [RFC4492] requires the definition and
>>>    assignment of additional NamedCurve IDs."
>>> 
>>> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it
>>> to be used for key exchange.  But what about "(client or server)
>>> authentication through reference in X.509 certificates..."?
>>> 
>>> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
>>> create one?  Or could we simply define some new ASN.1 Object
>>> Identifiers in your draft?
>> 
>> Yes perhaps.  What would the purpose of using Curve25519 in X.509
>> certificates be?
> 
> I just thought it seemed like a logical thing to do.  We can already do ECDHE-ECDSA using the NIST curves for both keys in certs and for key exchange, so why wouldn't we allow Curve25519 to be used for both purposes?
> 
> Unless NIST can prove that their curves aren't backdoored, I think it's likely that some folks (rightly or wrongly) will want to do ECDHE-ECDSA without touching the NIST curves at all.  What options do they have?

Umm, the brainpool curves are available.

Also, I don't get why performance would be less critical than that of ECDHE. In a full handshake, you do both an ECDSA signature and the ECDHE operations. Why would one matter while the other does not?

Yoav