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

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Jan 2014 17:18:54 +0100

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.

2) Additional curves for TLS.  This reflect the idea I had recently
after reading draft-ladd-safecurves.  However it seems there is still
many things to discuss and that it is not near the maturity of the
curve25519 part.  The following draft is also pending on the CFRG
discussions and maturity of draft-ladd-safecurves.
<http://tools.ietf.org/html/draft-josefsson-tls-additional-curves>.
Several people suggested to remove some curves from the list, and I'm
inclined to agree, but haven't made the change yet.  I'm not sure we
have a solid understanding of which curves makes sense and which doesn't
yet.

Eventually the drafts may be merged, if/when closure is reached on the
open issues for the second draft.  But I don't have high hopes that will
happen in the near term, and I believe there is growing interest in
moving forward with the first draft.

The drafts are on gitorious, if anyone prefers to send patches that way,
see: https://www.gitorious.org/ietf-simon/tls-curve25519/

Cheers,
/Simon

---

From: Rob Stradling <[email-masked]>
Date: Wed, 22 Jan 2014 18:07:25 +0000

On 22/01/14 16:18, Simon Josefsson wrote:
<snip>
> prove me wrong with comments or preferrably patches to the draft.

Simon, Section 2.1 says:
   "Since Curve25519 are not designed to be used in signatures, clients
    who offer ECDHE_ECDSA ciphersuites and advertise support for
    Curve25519 in the elliptic_curves ClientHello extension SHOULD also
    advertise support for at least one other curve, suitable for ECDSA.
    Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common
    curve is Curve25519."

Why is that "SHOULD" not a MUST?

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Robert Ransom <[email-masked]>
Date: Wed, 22 Jan 2014 13:16:20 -0800

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jan 2014 16:54:57 -0500

> * The draft still specifies a big-endian point format

Yes, this is a serious flaw, arguably reason enough to "vote no"

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Jan 2014 00:44:56 +0100

> Why is that "SHOULD" not a MUST?
The idea is that, if a client offers ECDHE_ECDSA ciphersuites but no
ECDSA-capable curve, the handshake can still be completed if non-ECDSA
ciphersuites are offered too: the server will select one of these suites. In
this case, offering ECDHE_ECDSA suite is just a waste of bytes, but does not
harm interoperability.

Making it a SHOULD may simplify client-side implementations in which the user
can select the list of supported curves and ciphersuites, by allowing the
implementation not to filter the list of ciphersuites based on the selected curves.

Manuel.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Jan 2014 01:22:40 +0100

> compatibility with them seems especially unwise.)
I have no objection to changing the byte ordering if nobody speaks up for
big-endian in the next few days.

> by an active attacker using that difference.

I wasn't aware that some implementations ignored the most significant bit. Out
of curiosity, could you cite examples?

One of the "selling points" of Curve25519 is that no public key validation is
needed, so I find it quite unfortunate that after all there is something to do
when receiving public keys.

> (b) Future specifications
This is a serious concern indeed. By the way, there was another issue under
discussion that is related: should the point format be just the 32 bytes, or
should we use a leading byte to follow the existing practice from X9.62, as Salz
Rich suggested? If we use a leading byte, maybe it's better to have two formats,
one for "x coordinate only", one for "y + bit sign of x"?

> basepoint for use in ECDH.
Of course it's no problem to add it. Do you think we should explain the
arithmetic too (Montgomery ladder + differential addition formulas)?

> which types of information leakage does the countermeasure render
I'm not aware of any specific analysis of this countermeasure for this type of
curves.

> ‘secp256k1’), and their names also end in “k1”.
Right, this should have been corrected already.

Manuel.

---

From: Robert Ransom <[email-masked]>
Date: Wed, 22 Jan 2014 17:17:37 -0800

> of curiosity, could you cite examples?

curve25519-donna and -donna-c64 ignore the MSB.

Nick Mathewson (Tor lead developer) tested whether Dr. Bernstein's
floating-point implementation for IA-32 in NaCl ignores the MSB; he
reported that it does.

The ‘ref’ implementation in NaCl does not ignore the MSB.

I have no idea what Dr. Bernstein's original floating-point Curve25519
implementation for IA-32 does with the MSB, but the web page
documenting it hints that it treats the MSB as part of the x
coordinate.

> when receiving public keys.

Fingerprinting of implementations wasn't one of the security concerns
that Dr. Bernstein had in mind at the time, and it still isn't widely
considered to be a security risk.  It's certainly minor compared to
the numerous ways that NSA-curve ECDH implementations can leak their
keys.

But the bigger reason to mask off the high bit is extensibility.

> one for "x coordinate only", one for "y + bit sign of x"?

* You appear to be confusing Montgomery form with Edwards form.  The
Curve25519 paper specifies ‘Montgomery-form x coordinate only’; the
other format you are suggesting seems to be ‘Edwards-form y coordinate
with sign bit of Edwards-form x coordinate’.  (Remember that the
Edwards-form y coordinate is analogous to the Montgomery-form x
coordinate.)

* There is no reason to ever transmit an Edwards-form y coordinate for
use in ECDH.  The formats that would be useful here are
‘Montgomery-form x coordinate only’ and ‘Montgomery-form x coordinate
with sign bit of Edwards-form x coordinate’.

* If you do not add a leading point-format byte, there is no reason to
specify the meaning of the high bit in this document.  If you do add a
leading byte, you will have to choose in this document whether the
sign bit is for the Edwards-form x coordinate or the Montgomery-form y
coordinate.

* Some future applications may wish to transmit an uncompressed
Edwards-form x coordinate or Montgomery-form y coordinate, not just
the sign bit.  If you add a leading byte, you'll have to choose which
coordinate to use now.  Alternatively, you could specify that
implementations of this document accept 64-byte points and ignore the
second half of the point structure.  (Note that this means
implementations of this protocol MUST ignore the second half, even if
they know how to use it in some other protocol, or they will be
distinguishable from other ECDH implementations.  I don't think that
restriction will ever be a problem for ECDH implementations.)

* Some future (non-ECDH) applications may wish to transmit an
Edwards-form y coordinate instead of a Montgomery-form x coordinate
(e.g. so that they can distinguish the point of order 2 from the
identity).  If you do not add a leading point-format byte now, those
applications will have to use a different NamedCurve in order to
indicate that they are incompatible with the point formats used for
ECDH.  (I'm not sure that this is a problem, or that any such
applications will ever exist.)

I'm currently leaning towards ‘just reserve the high bit and tell
implementations to accept and ignore the second half of a 64-byte
point structure’, but there may be good enough arguments for using a
magic byte to justify the minor downsides.

> arithmetic too (Montgomery ladder + differential addition formulas)?

Only if you will do it well.

> I'm not aware of any specific analysis of this countermeasure for this type

Then either (a) don't recommend that countermeasure as an alternative
to using constant-time field operations, or (b) explicitly warn that
there is no evidence that that countermeasure will be sufficient to
protect against side-channel attacks.

Robert Ransom

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Jan 2014 22:42:35 -0800

> Yes, this is a serious flaw, arguably reason enough to "vote no"

Endinanness is never a good reason to vote no.

Please read http://www.ietf.org/rfc/ien/ien137.txt if you do not believe this.

What you are complaining about takes three lines of C to fix.
Let's not reignite a holy war that the IETF settled long ago.
Sincerely,
Watson Ladd
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 23 Jan 2014 09:39:33 +0100

> compatibility with them seems especially unwise.)

An Internet protocol is not typically designed based on the existing
implementations limitations and they it is often expected to outlive
them. Almost all IETF protocols use the big-endian format for
transferring integers, and implementations of these protocols in have
already ways to convert these numbers to the native endianess. 

regards,
Nikos

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Jan 2014 10:34:57 +0100

On 23/01/2014 02:17, Robert Ransom wrote:
> [...] 
> [...]

Ok, thanks for the information.

> But the bigger reason to mask off the high bit is extensibility.
I fully agree it's the bigger reason. As discussed below, there is probably some
other ways to achieve extensibility, so if extensibility wasn't a concern, would
you think that avoiding implementation fingerprinting is more valuable than
being able to accept any string as a public key without no validation or masking?

> Edwards-form y coordinate is analogous to the Montgomery-form x
I misinterpreted your suggestion indeed. I read "Edwards" and immediately
thought that you were talking everything in Edwards form (hence the y
coordinate), which would have made little sense in this context.

> sign bit is for the Edwards-form x coordinate or the Montgomery-form y
Or we could add a leading byte now and say that the meaning of the msb is not
defined yet an reserved for future use (which is what you suggest anyway, IIUC).
Then a future document could update the meaning of this leading byte.

> restriction will ever be a problem for ECDH implementations.)
I'm afraid I didn't get your point. Why would we have to choose which coordinate
to use now? If we add a leading byte meaning "the 32 bytes of the x coordinate
(Montgomery form) follow"[1], and if people later want to be able to transmit
two full coordinates, then they will pick a new leading byte and they will have
to choose which coordinates to use with it, not us.

[1] With some clarification about the msb as discussed above.

> applications will ever exist.)
My humble opinion is that those applications should use a different NamedCurve
indeed.

> magic byte to justify the minor downsides.
Transmitting 64 bytes when 33 (32 + leading byte allowing future extensions) are
enough will probably be seen as a waste by many people.

> protect against side-channel attacks.
Right.

Manuel.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 23 Jan 2014 11:03:24 +0000

> implementation not to filter the list of ciphersuites based on the selected curves.

OK, that makes sense.

BTW, since other NamedCurves may be defined in the future that "are not 
designed to be used in signatures", how about changing...

   "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common
    curve is Curve25519."

...to...

   "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no
    common curves suitable for ECDSA."

?

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 23 Jan 2014 12:06:32 +0100

> OK, that makes sense.
I'm glad you agree.

>     common curves suitable for ECDSA."
Yes, absolutely.

Manuel.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jan 2014 10:13:55 -0500

Would you prefer it phrased this way:  "pointlessly breaking compatibility with existing implementations is reason enough to vote no"

	/r$

---

From: Robert Ransom <[email-masked]>
Date: Thu, 23 Jan 2014 10:33:30 -0800

> already ways to convert these numbers to the native endianess.

*This* Internet protocol is motivated by the existing implementations
for Curve25519.  What is the *technical benefit* of deliberately
breaking compatibility with the implementations which justify this
protocol's existence?

Robert Ransom

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 23 Jan 2014 10:40:16 -0800

> applications will ever exist.)

Can someone remind me why any of the above is better than using
ECPointFormat to specify the point format?

--Andy

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jan 2014 13:46:43 -0500

> Can someone remind me why any of the above is better than using ECPointFormat to specify the point format?

Because ECPoinrtFormat requires X and Y cords and Curve25519 has no Y.

There is discussion about having a "defined by the curve" ECPointFormat; how to move such a proposal forward is being discussed by the Security Area Directors, who owe as a response "soon" (see http://www.ietf.org/mail-archive/web/tls/current/msg11139.html )

	/r$

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 23 Jan 2014 10:52:59 -0800

> Because ECPoinrtFormat requires X and Y cords and Curve25519 has no Y.

Why is "defined by the curve" (where said definition may not actually
allow x and y to be computed) less of a departure from the current
ECPointFormat than, say, "Montgomery form x and sign bit of Edwards
form x"?  It's already the case that not all point formats are
applicable to all curves.

-- 
Andy Lutomirski
AMA Capital Management, LLC

---

From: Robert Ransom <[email-masked]>
Date: Thu, 23 Jan 2014 11:08:16 -0800

> ECPointFormat to specify the point format?

As far as I can tell from the spec, ECPointFormat is used only to tell
parties what point formats their communication partner can process,
not to describe the format of an actual point.  (That's why the point
formats referenced by RFC 4492 include a leading magic byte.)

ECPoint must be self-describing within the scope of a given curve.

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Thu, 23 Jan 2014 11:45:37 -0800

On 1/23/14, Manuel Pégourié-Gonnard <[email-masked]> wrote:
>>> I wasn't aware that some implementations ignored the most significant
>>> bit.
>>> Out

Samuel Neves reports that Dr. Bernstein's original Curve25519
implementation for IA-32 does ignore the high bit.

So, the only implementation I know of that does not ignore the MSB is
a horribly slow one that should never be used in production -- I would
not be surprised if it's slower than a typical implementation of the
BND curves.

> being able to accept any string as a public key without no validation or

I still think that avoiding implementation fingerprinting would
justify “implementations SHOULD mask off the high bit”.

Remember that what Dr. Bernstein refers to as ‘public key validation’
in the Curve25519 paper is considerably more expensive than one
bitwise AND:

* With typical (non-twist-secure) curves in x-coordinate-only form,
the recipient must compute the Legendre/Jacobi symbol of x^3 + c*x^2 +
a*x + b in order to avoid operating on the twist.  With Curve25519,
the twist is as secure as the curve which contains the basepoint, so
operating on the twist does not expose the secret key to any useful
attacks.

* The standard advice for handling curves with cofactor >1 is to check
that it is a member of the prime-order subgroup before using it; this
effectively performs the scalar multiplication operation twice.
Curve25519 avoids this by (a) masking secret keys to be divisible by
the cofactor, so the output will be in a subgroup of large-prime order
regardless of the input; and (b) ignoring the widespread
recommendation to reject ECDH keys which have small order.

> Then a future document could update the meaning of this leading byte.

I think that's easiest (provided that current implementations also
accept 64-byte points and discard the second half; see below).

> [1] With some clarification about the msb as discussed above.

If a future protocol wants to be compatible with implementations of
this protocol, this protocol must specify some form of extension hook.

If you choose a leading byte as the only extension hook, you must
reserve a few alternate leading bytes now, along with enough
information about the formats they will eventually describe that
current implementations will be able to dig a Montgomery-form x
coordinate out of the ECPoint blob.

If you add a leading byte as an extension hook *and* specify an
ECPointFormat value for the current ‘Montgomery-form x’ point format,
current implementations can refuse to receive point formats which they
won't understand.  (This has the slight theoretical disadvantage that
if a future protocol specifies time-based authentication of servers'
ECDH public keys (to avoid the overhead of one signing for each client
connection), implementations of that future protocol may have to sign
more than one type of Curve25519 key per time period.  I don't think
this will be a real problem.)

If you don't add a leading byte, I think the ECPoint length byte can
still be used as an adequate extension mechanism for future non-ECDH
protocols.

> My humble opinion is that those applications should use a different

OK.  (Like I said, I'm not sure that anyone will ever want to do that.)

> enough will probably be seen as a waste by many people.

I agree, but future implementations should be allowed to send an
uncompressed second coordinate without breaking compatibility with
implementations of this protocol.  What I'm suggesting is that (a)
current implementations send 32-byte points; (b) current
implementations accept both 32-byte and 64-byte point objects, and
ignore the second half of a 64-byte point.

Robert Ransom

---

From: James Cloos <[email-masked]>
Date: Thu, 23 Jan 2014 15:38:17 -0500

>>>>> "MP" == Manuel Pégourié-Gonnard <[email-masked]> writes:

MP> I have no objection to changing the byte ordering if nobody speaks
MP> up for big-endian in the next few days.

Internet-endian is the better choice.

Coding is thusly is not a problem, and as the tls libs -- or their
number-crunching libs -- gain support they can code to expect 'net-
endian keys.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Robert Ransom <[email-masked]>
Date: Thu, 23 Jan 2014 13:37:18 -0800

> accept 64-byte points and discard the second half; see below).

On further thought, there is a major technical benefit to sending
(either all of or a sign bit for) the Edwards-form x coordinate rather
than the Montgomery-form y coordinate.  Denoting the Montgomery-form
point as (u, v) and the Edwards-form point as (x, y), the isomorphism
from Montgomery form to Edwards form computes x = 2 u/v, which is
undefined for the point of order 2 (Montgomery (0, 0)).

I think that issue, combined with the fact that implementations which
use the sign bit will almost certainly use Edwards form internally,
should rule out any use of a Montgomery-form y coordinate in any
current or future protocol.

Since Curve25519's coordinate field order is congruent to 5 mod 8,
there is no notion of ‘principal square root’, and thus no plausible
alternative to using the least significant bit of a coordinate as its
sign bit.  So there is only one likely choice of sign bit for
Curve25519 group elements, and that is the LSB of the Edwards-form x
coordinate.

Now that I'm not worried about what will eventually be chosen as the
sign bit, the only reason I can see to use a leading magic byte in the
point format is to distinguish ‘the sender did not compute the sign
bit of this point’ from ‘the sender computed the sign bit of this
point, and it is 0’.  I have previously suggested that distinguishing
those cases could be useful, but now I think mitigation of
implementation fingerprinting is more important -- I see no reason to
advertise whether an implementation computes the sign bit of its group
elements or not, even if an attacker could infer that piece of
information after a series of connections.

Robert Ransom

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 24 Jan 2014 19:49:43 +0100

> not be surprised if it's slower than a typical implementation of the
Good to know. It really pleads for recommending to ignore the MSB even if we
don't need it later.

> justify “implementations SHOULD mask off the high bit”.
I agree.

> in the Curve25519 paper is considerably more expensive than one

Sure.. Another point I thought about in the meantime is that the security
consequences of not doing that check are minimal for Curve25519 (implementation
fingerprinting) as opposed to short Weierstrass curves with (x, y) coordinate
(small subgroup attack).

> won't understand.

Haha, I think I finally understood. You're referring to this paragraph of the
draft, right?

   Since only one point format can be used with Curve25519, which is
   distinct from the formats used by short Weierstrass curves, the
   contents of the "Supported Point Formats" extension is irrelevant for
   this curve.

Yes, if we add a leading byte, and we want to be able to use other formats
(hence other leading bytes) with Curve25519 in TLS in the future, then this
phrase should be removed and a new ECPointFormat value requested from IANA.

> still be used as an adequate extension mechanism for future non-ECDH
As long as there is no more than one future format mapping to the same length.
Eg, is for some reason some people want to send

> ignore the second half of a 64-byte point.
That's an option too, but compared to a leading byte, it doesn't allow to define
two different 64-byte point formats in the future, right? So maybe the leading
byte (with ECPointFormat negociation) is the most future-proof way.

Manuel.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 24 Jan 2014 20:04:23 +0100

> breaking compatibility with the implementations which justify this
While I can see your point, I feel "breaking compatibility" is a bit of an
overstatement. Swapping bytes when points are written/read is no difficult task
and could be done in the TLS-specific portion of the code before passing the
point from/to one of the existing implementations of Curve25519 arithmetic.

Of course it does not invalidate your point that existing implementations are an
important motivation for this draft, and that there is no technical benefit to
big endian (if you don't count uniformity with other formats as technical), but
I think it's worth noting that we're not discussing whether using the existing
implementations will be *possible* but only *how easy* it will be.

Manuel.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Jan 2014 15:19:01 -0500

> While I can see your point, I feel "breaking compatibility" is a bit of an overstatement. Swapping bytes when points are written/read is no difficult task and could be done in the TLS-specific portion of the code before passing the point from/to one of the existing implementations of Curve25519 arithmetic.

Sure, and we could also use the existing ECC point structure and transmit 32 bytes of zero as a fake y value.  It's a slippery slope.
 
The main interest in using this curve is to use the existing implementations for their security and performance benefits and that there is a real benefit to being able to feed directly from the wire into implementations.  On the "other side" the only argument seems to be that this format is what all other protocols do.

So explain to me which "side" is following religious dogma? :)

	/r$

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 24 Jan 2014 21:32:53 +0100

> So explain to me which "side" is following religious dogma? :)
I don't think I ever accused you, or anyone else, of following a religious dogma

> big-endian in the next few days.

As it happens, a few people spoke for big-endian, but it should be noted the
above phrase has only an "if" clause, not an "if and only if" :)

Manuel.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Jan 2014 15:34:44 -0500

> I don't think I ever accused you, or anyone else, of following a religious dogma in this discussion

No, you never did and I'm sorry if I gave that impression.  I should have removed all names from the headers and sent it just to tls.

	/r$

---

From: Robert Ransom <[email-masked]>
Date: Fri, 24 Jan 2014 13:17:59 -0800

> fingerprinting) as opposed to short Weierstrass curves with (x, y)

Yes.

> Haha, I think I finally understood. You're referring to this paragraph of

Yes, I am.

> phrase should be removed and a new ECPointFormat value requested from IANA.

Yes.

> byte (with ECPointFormat negociation) is the most future-proof way.

Yes.  (Even though I am now convinced that there is only one
reasonable choice for the other coordinate for Curve25519.)

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Sat, 25 Jan 2014 01:18:32 -0800

On 1/25/14, Nikos Mavrogiannopoulos <[email-masked]> wrote:
>> Sure, and we could also use the existing ECC point structure and transmit
>> 32
>> bytes of zero as a fake y value.  It's a slippery slope.
>>
>> The main interest in using this curve is to use the existing
>> implementations
>> for their security and performance benefits and that there is a real
>> benefit
>> to being able to feed directly from the wire into implementations.  On
>> the
>> "other side" the only argument seems to be that this format is what all
>> other protocols do.
> You seem to imply that following conventions established during the years is
> unecessary. That could be true, but your only point of backing that up is
> that a library that implements this curve uses the little endian format.

Several libraries implement Curve25519 scalar multiplication in
constant time, with varying degrees of portability and efficiency.
All of them operate on public and secret keys in little-endian format.

> Is
> there really merit in that argument?

Yes.

> Do you really believe that all
> implementations of this draft will use this library?

I sure hope all implementations of this draft will use a constant-time
implementation of Curve25519.  Since the most likely way that a TLS
implementation will obtain a constant-time implementation of
Curve25519 is to use an existing one, I hope all TLS implementations
will initially use one of the existing little-endian implementations
of Curve25519.

> Why force any other
> library that will implement this curve handle its points in a special way?

Does this mean that you intend to implement Curve25519 using a generic
bignum library?  How will your implementation (attempt to) avoid
leaking information about key material to a side-channel attacker?

> This is not about standardizing code, it is about standardizing a curve.

It is about standardizing a curve which has a well-established
convention of storing and transmitting keys in little-endian format.

Robert Ransom

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 27 Jan 2014 10:30:01 +0100

> All of them operate on public and secret keys in little-endian format.

I still cannot see your argument here. Is there a requirement for this
curve to be implemented or do these libraries use little-endian format
because it suits them better (e.g., they target little endian systems)?
This is an honest question as I don't know the answer.

> leaking information about key material to a side-channel attacker?

Do you mean about power analysis (e.g., constant power consumption or
time)? Why would that matter for the protocol in question? As I
understand the document specifies additional curves for ephemeral
key exchange (ECDHE), so side channels are not a threat.

> convention of storing and transmitting keys in little-endian format.

I believe that software does the transmitting rather than the curve
itself, so that I think that my point of not standardizing software but
a curve is still valid.

regards,
Nikos

---

From: Robert Ransom <[email-masked]>
Date: Tue, 28 Jan 2014 06:34:09 -0800

> This is an honest question as I don't know the answer.

Curve25519 has a standard format for public and secret keys:
little-endian.  Several independent implementations, each of which has
its own advantages and disadvantages, conform to that standard.
Because each of them implements the existing standard key formats for
Curve25519, they interoperate with each other.

Complying with the existing, little-endian, standard for Curve25519
key formats would have the major technical advantage that TLS
implementations can use existing, off-the-shelf Curve25519
implementations without the unnecessary additional complexity of
reversing the bytes of Curve25519 inputs and outputs.

I have not seen a compelling *technical* reason for TLS to disobey the
currently existing, currently implemented Curve25519 standard by
reversing the bytes.

> time)? Why would that matter for the protocol in question?

Timing attacks can be (and have been) performed successfully on the
public-key portions of TLS implementations across a network.  They do
not require measurements of a server's power supply, as you seem to be
implying.

Data cache attacks are also relevant for all TLS implementations run
on hardware shared among parties who do not trust each other (e.g.
virtual private servers).

> As I

Side channels are a threat to every protocol implemented in software,
unless the implementation guarantees that secret information is not
made available to any hardware component which may leak it.

> itself, so that I think that my point of not standardizing software but

The existing Curve25519 software represents the rough consensus and
running code of several parties.  There are at least two independent
implementations (Dr. Bernstein's original and Adam Langley's
curve25519-donna).  As far as IETF is concerned, the existing
little-endian key formats for Curve25519 *are* a standard.

If you have a *technical* argument that justifies disregarding the
existing standard for Curve25519 key formats, please state it.

Robert Ransom

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Jan 2014 09:56:58 -0500

> I have not seen a compelling *technical* reason for TLS to disobey the currently existing, currently implemented Curve25519 standard by reversing the bytes.

Right.

---

From: Bill Frantz <[email-masked]>
Date: Tue, 28 Jan 2014 16:11:34 -0800

There is two thing that all long-term endian warriors have in 
common. (1) They have a strong opinion about what the right 
answer is; and (2) They wish the other side had won a complete victory.

In this spirit, please look at RFC1762 which says:

       Exactly one length field and one DNA Phase IV Routing 
packet are
       encapsulated in the information field of a PPP Data Link Layer
       frame where the Protocol field indicates type hex 0027 
(DNA Phase
       IV Routing).  The length field contains a count of the 
number of
       octets in the DNA Phase IV Routing packet.  It is two 
octets in
       length itself, and is stored in VAX byte ordering, to be more
       consistent with DNA Phase IV Routing over Ethernet (i.e. least
       significant byte first).  It is needed to disambiguate optional
       padding octets from real information.

So it would not be unprecedented to have little endian data in 
an Internet Protocol.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032