Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

[Robert Ransom <[e-mail]>]

On 1/22/14, Simon Josefsson <[e-mail]> wrote:
> All,
>
> I have updated the Curve25519 draft.  I believe people are implementing
> Curve25519 for TLS.  My idea of adding the "additional" curves to the
> same draft seems like a mistake, or at least the timing of doing it was
> a mistake.  Merging all curves into one draft makes it harder to
> evaluate consensus and maturity around the Curve25519 part, which I
> hope/believe we are approching.  Thus, I have split the draft into two
> drafts:
>
> 1) Curve25519 for TLS.  This was the original scope of the draft.  The
> URL is: <http://tools.ietf.org/html/draft-josefsson-tls-curve25519>.  As
> far as I know, there are no outstanding issues, and it is possible to
> implement and deploy Curve25519 in TLS following the draft.  Please
> prove me wrong with comments or preferrably patches to the draft.

* The draft still specifies a big-endian point format.  What is the
technical benefit of requiring every TLS implementation which uses one
of the existing efficient, secure implementations of Curve25519
Montgomery-form scalar multiplication to reverse the byte order of its
input and output?  (Note that people want to use Curve25519 in TLS
because of those existing implementations, so deliberately breaking
compatibility with them seems especially unwise.)

* The draft should specify that implementations MUST discard (i.e. set
to zero) the most significant bit of a received public key, for two
reasons: (a) Existing Curve25519 scalarmult implementations differ in
their handling of inputs with that bit set, and could be distinguished
by an active attacker using that difference. (b) Future specifications
may wish to include the sign bit of an Edwards-form x coordinate in a
Curve25519 point format for use with other protocols (e.g. Schnorr
signature, Ace) without breaking backwards compatibility with use in
ECDH.

* The draft does not specify the curve equation of Curve25519 or the
basepoint for use in ECDH.

* The ‘Security Considerations’ section suggests that Curve25519 can
be implemented securely using bignum libraries which leak information
about the numbers they operate on to a side-channel attacker, as long
as the internal projective representation of each point is randomized.
 Has this proposed side-channel countermeasure been evaluated?  If so,
which types of information leakage does the countermeasure render
harmless?

* The draft claims that every curve listed in RFC 4492 whose name ends
in “k1” is defined over a binary (characteristic 2) field.  This is
false: RFC4492 defines several GLV curves over prime fields (e.g.
‘secp256k1’), and their names also end in “k1”.


Robert Ransom