Subject: [Cfrg] A way out of the little/big endian dispute?

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Mar 2015 22:26:48 -0400

Rather than specifying a default endian setting for Curve25519,
specify the encoding for TLS

To get interop, we have to specify more than just big/little in any
case. We are specifying bits on the wire of a structure.

Now since we are talking about TLS on the wire here we are actually
breaking the TLS spec which states it is network byte order. Which
should have absolutely disqualified the original Curve25519
submission. But nobody caught it at the time and here we are.

So the spec should describe the TLS encoding to be used using TLS
schema etc, and state that this encoding is little endian.

But that does not set any precedent for representing the key
information etc in PKIX which is an ASN.1 based encoding. All the
existing KeyInfo specifications are in Big Endian form and if anyone
wants to change that they should take it up with the IAB which made
the call on network byte order back when IMPs were still valve
powered.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 27 Mar 2015 19:38:07 -0700

Was there something at the meeting I missed? The results of the poll
weren't announced from what I saw, but by my count the CFRG prefers little
endian

On Fri, Mar 27, 2015 at 7:26 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

-- 
Tony Arcieri

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Mar 2015 23:04:45 -0400

There are two issues, one is what the group decides, the other is what
the IETF decides.

The endian decision was one of the first decisions taken by the IETF
(before there was an IETF) and it is a decision that there is
traditionally a very great deal of reluctance to re-open. Most members
of the IESG cannot understand the details of the elliptic curve
decisions but everyone can have an  opinion on endian-ness (some have
two or even more).

Reducing the size of the ask to the bare minimum is usually best.

So constraining the

On Fri, Mar 27, 2015 at 10:38 PM, Tony Arcieri <[email-masked]> wrote:
> Was there something at the meeting I missed? The results of the poll weren't
> announced from what I saw, but by my count the CFRG prefers little endian
>
> On Fri, Mar 27, 2015 at 7:26 PM, Phillip Hallam-Baker
> <[email-masked]> wrote:
>>

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 27 Mar 2015 20:11:31 -0700

On Fri, Mar 27, 2015 at 8:04 PM, Phillip Hallam-Baker <[email-masked]

> There are two issues, one is what the group decides, the other is what

Right, but the latter discussion sounds like something that should take
place outside of the scope of the CFRG.

-- 
Tony Arcieri

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 28 Mar 2015 08:06:47 +0000

On 2015-03-28 02:26, Phillip Hallam-Baker wrote:

> breaking the TLS spec which states

No. The TLS WG explicitly declared the internals such as point formats
of all new curves being specified - i.e. ours - to be completely
opaque byte vectors to the TLS protocols and structures.

All details of formats and endianness are explicitly _our_ problem,
and not theirs. I surmise they'd prefer them to as close to the crypto
and simple as possible, not abstracted away behind dreadful ASN.1
bigints.

I don't feel there's a dispute remaining: we seem to have overwhelming
consensus on little-endian.

- -- 
/akr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Mar 2015 13:59:46 +0200

> the call on network byte order back when IMPs were still valve

I think it is a bit more subtle than that:

- The field containing the key itself is defined as BIT STRING.
- The algorithm field sets the format of that.
- The only current ECC signature capable algorithm is ECC point
  with unrestricted operations (seriously?).
- That algorithm specifies that the encoded point can be
  uncompressed or compressed using <something> compression.
- That compression compresses Y (whereas Edwards usually
  compresses X).
- Uncompressed is MUST, compressed is MAY.

Of course, some PKIX folks really don't like when you put
non-ASN.1 into various BIT STRING / OCTET STRING fields.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Mar 2015 21:42:33 +0000

On Fri, Mar 27, 2015 at 10:26:48PM -0400, Phillip Hallam-Baker wrote:

> existing KeyInfo specifications are in Big Endian form

The ASN.1 representations of *integers* is big-endian.  The "x"
(or "u") coordinate for ECDH per the proposed specification is an
octet-string, not an integer.

Indeed already with EC crypto in X.509 we have at the top of
page 17 of:

    https://tools.ietf.org/html/rfc3279#section-2.3.5
    (i.e. <https://tools.ietf.org/html/rfc3279#page-17>)

   The elliptic curve public key (an ECPoint which is an OCTET STRING)
   is mapped to a subjectPublicKey (a BIT STRING) as follows:  the most
   significant bit of the OCTET STRING becomes the most significant bit
   of the BIT STRING, and the least significant bit of the OCTET STRING
   becomes the least significant bit of the BIT STRING.  Note that this
   octet string may represent an elliptic curve point in compressed or
   uncompressed form.  Implementations that support elliptic curve
   according to this specification MUST support the uncompressed form
   and MAY support the compressed form.

No little-endian or big-endian integers in sight.  Just serialize
the octet string into a bitstring.  The interpretation of the octet
string is (bottom of page 14):

   The value of ECPoint SHALL be the octet string representation
   of an elliptic curve point following the conversion routine in
   [X9.62], Section 4.3.6.  Note that this octet string may represent an
   elliptic curve point in compressed or uncompressed form.

So we already have a clear separation of duties where the crypto
algorithm determines and knows the point encoding, and the X.509
layer just sees opaque octet-strings (serialized into bit strings).

So there is nothing new in this regard in a proposal to encode
points for a new set of algorithms as octet strings in a way that
is most suitable for those algorithms.  The octet-strings for EC
have been and remain opaque inputs to the underlying algorithms.

-- 
	Viktor.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 29 Mar 2015 23:33:00 -0700 (PDT)

On Sat, March 28, 2015 1:06 am, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

  Big endian != ASN.1, I don't know where that's coming from. Check
out htonl(), it makes big endian and it involves absolutely no ASN.1.

> consensus on little-endian.

  There certainly is a collective that is pushing for little-endian. Not that
I'm suggesting any such thing but if we were to base one's voice in the
matter on how long that person has been on this list we'd get a much
different result.

  Big endian has been the wire format for decades. And now all of a
sudden we're told to rubber stamp a little endian format just because.
Because that's how it was done and we can't change it, ignoring the
fact that little endian is the change.

  Dan.

> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJVFmELAAoJEOyEjtkWi2t6EPcQAItcwrENtI3aAB3UOMD1sqwP
> dDU8SsPEKTSxOU4/aJWg1CFvmbbDZg3sFepUnB80yUcXC4wkfC4/YLFxjoJcakCS
> NC+cHHg6e1j62GNjrNbNQniV+e2N4cU7190vO0kPDiyrXwVxlUUSRBpXNV9IMwXZ
> fduDgcHDd/F/zn53htXJ4LnrLpL5An5/Ets0fYs7IjrjmscaPSWf/W3mqHvwxsf+
> YpAU0Q2svH2oD34qN9GqNnB5dIUfJ3ZmqeggLeohM3565In3pfItasaOioXlHE1G
> gCvOot9+ySmqfm0jkv3tQWmKVEbCfpw2jyycXd7ZANUcxpGbspPI3kkVRTBkwxHt
> UP9xXt7RUMkyc7XUK//SzG/xQtNKMSc0kXUAuS1ZcXEd4r9ggcrFcL51o7rwujlH
> IaualdHFnTmB3HmWUI0ANYOD8q6lrrIFcpBvum1ZHOZMu+EeOi8P3Y4+4fGRZc7R
> nOoWD9ZvyBWP6JdoH4kAVsMUV8fK+Y7/bP3YiU864VnvHZwtbaWpjH9SV8FJq+x/
> F+PcHWyCi2ck67dzWHzuIaAp3jsh32t05iMyi8XhF5jNjlcBlvuyOF4vzCc85aTp
> Ioz0I2HomZHbLEA5Igr7u0elcp/o3QkO/beCCZTjEJ6Jk59t53phReb4fafEeBsC
> Uk5uAUhrOLA2PxS7Qg/F
> =ZTrH
> -----END PGP SIGNATURE-----
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Mar 2015 06:53:22 -0700

> out htonl(), it makes big endian and it involves absolutely no ASN.1.

It takes an integer in an unknown range (size of int) and mungs it. How is
that relevant to turning a number in a much larger range into a string of
bytes?

> fact that little endian is the change.

Change for what and for who? I assume you don't have

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Mar 2015 06:59:22 -0700

> Change for what and for who? I assume you don't have

(Apologies for the premature send: This should continue as below)

an implementation that uses big endian. Of course, there is an ongoing
poll were very few people have stuck up for big endian. Perhaps its
because you've never been able to point to code in SSH that is more
complicated because of the use of little-endian in Curve25519, or
explain why a convention for the representation of short lengths in
network protocols has to determine the representation of opaque values
(which, as MD5 shows, it doesn't).

The whole issue is writing the function that computes the scalarmult.
You've never explained why this is made more difficult by
little-endian, while it's clear that parsing half of all fields in a
packet as little-enedian and half as big-endian is a pain. But it's
very clear that defining two functions with the same name is a bad
idea.

Sincerely,
Watson Ladd

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Mar 2015 10:58:57 -0400

On Mon, Mar 30, 2015 at 9:59 AM, Watson Ladd <[email-masked]> wrote:

> Perhaps its
> because you've never been able to point to code

Watson, I am almost 50. I have been earning a full time wage as a
professional programmer since I was 14 and it is now several decades
since I handed in my doctoral thesis.

In what universe do you think you can win that game?

This particular topic was being discussed in IETF before you were born:

https://www.ietf.org/rfc/ien/ien137.txt

> in SSH that is more

My concern isn't the complexity of code I am not going to have to
write, it is the fact that this proposal has to pass multiple levels
of IETF review and there can be no confidence in the outcome until the
final IESG sign off.

I know that if the TLS WG chooses big-endian there is absolutely no
possibility of the decision being overriden at a higher level and so I
can start telling folk to implement stuff the minute that there is a
spec.

Given that there is already TLS code and a spec, the scope for an
overturn there is quite small. But that argument does not carry over
to PKIX because there isn't PKIX code for Curve25519.

A proposal that attempts to re-open the network byte order decision
taken long before the IETF existed is almost certain to get a DISCUSS
vote and there is a very high probability of an appeal.

> very clear that defining two functions with the same name is a bad

Umm, my code that does bit packing has no connection whatsoever to my
scalarmult code. I cannot conceive of a situation in which I would
want the two to have any relationship whatsoever. It is called
structured programming.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 30 Mar 2015 07:59:28 -0700 (PDT)

>> that relevant to turning a number in a much larger range into a string

  It's a existence proof that one can represent integers in big endian
and not get "dreadful ASN.1" involved.

>>>   There certainly is a collective that is pushing for little-endian.
>>> Not
>>> that
>> Change for what and for who?

  Read what I wrote: "the wire format". So "for what" is for the wire format.
For who? For you. For me. For or the entire Internet community.

>                                                   I assume you don't have

  I have never discussed a person's SSH code or the difficulty in doing
scalarmult in big endian for a good reason… they have nothing to do
with representation on the wire. If one were of the opinion that
cleaner code and/or faster scalarmults can be had by implementing
as little endian then hey, bully for you. Implement little endian.

  In your SPAKE2 draft you have a table with points for 3 curves,
none of which are curve25519. You have previously said, and I
paraphrase here, that you don't know the endianness of those
bignums because you don't care. Which is right! And the reason
you don't have to care is because _the convention is big endian_,
everything is conveyed as big endian (note that that says nothing
about how anyone must implement the underlying library to
support those curves).

  If you were to put curve25519 points into your draft you would
have to note the endianness of everything now because people
would be forced to care in order to implement your draft correctly.

  It seems to me that what is being asked here is not just "let's
change the wire format to little endian for this particular curve",
it's "let's put the Imprimatur of the CFRG on a particular
_implementation_ of curve25519." That's a very different request
and something I don't think this group should be involved in.
We don't do rubber stamp here.

  Dan.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Mar 2015 15:03:44 +0000

> https://www.ietf.org/rfc/ien/ien137.txt

Times change. As the chairs have declared, we have rough consensus.  And, we have running code. :) Move on.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Mar 2015 08:14:51 -0700

> of IETF review and there can be no confidence in the outcome until the

So you are opposed not because you actually oppose this, but someone
else somewhere might be?

> can start telling folk to implement stuff the minute that there is a

But TLS isn't making the choice, we are.

> to PKIX because there isn't PKIX code for Curve25519.

Are the functions in tweetnacl.c PKIX code or TLS code? The correct
answer is neither: they are functions on 32 byte strings. I don't see
how PKIX benefits from changing the definition of these functions to
work on 32 byte strings in the opposite direction.

> want the two to have any relationship whatsoever. It is called

It's called library design: forcing users to write boilerplate code
that calls separate unpacking, crypto, and packing functions as
compared to a single call that does all of that is a worse idea.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Mar 2015 16:20:21 +0100

Phill,

> to PKIX because there isn't PKIX code for Curve25519.

I'd be quite surprised myself if the TLS WG wanted to change what
the CFRG have picked given they asked for the representations
to be done by CFRG I think. We'll see though.

> vote and there is a very high probability of an appeal.

I believe you are incorrect there both ways. And I do not think
it even remotely valuable to speculate about IESG evaluation nor
about appeals at this time. If some AD put on a DISCUSS about that
I'd be highly animated in telling them that they absolutely need
to point our how precisely their ballot meets the IESG discuss
criteria, which explicitly rules out the idea that we ADs try impose
our personal technical preferences when that's contrary to IETF
consensus. (We are used to holding our noses a lot actually, and
I doubt that'd happen, except perhaps with a new AD - I made that
exact mistake myself at first and got quickly and thoroughly
eviscerated for it, which is a fine cure:-)

The poll was polled. Let's see how the CFRG chairs summarise the
results (or did they already?).

S.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Mar 2015 08:22:11 -0700

> as little endian then hey, bully for you. Implement little endian.

If the wire representation doesn't actually affect the caller of the
curve25519 function, or the implementation, what's the problem?

> about how anyone must implement the underlying library to

If you actually read the draft, you would see these aren't numbers but
strings of bytes, and SEC1 determines what they mean.

> would be forced to care in order to implement your draft correctly.

Imagine I had a group that wasn't written down as numbers, but as
permutations. I still wouldn't have to care: I would just note which
format was being used. It's entirely irrelevant that these strings are
a byte followed by a packed bignum: all sensible code calls the
appropriate unpack function for the group, no matter what that unpack
function does internally. In fact, I don't see why I ever have to
explain how group elements are written down, instead of pointing to
the relevant standard explaining how those elements are written down.

> We don't do rubber stamp here.

And which implementation do you think we're putting the imprimatur on?
Because there are multiple, independent implementations that all use
little-endian.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 18:27:04 +0300

> vote and there is a very high probability of an appeal.

That’s quite a bit of FUD. At worst, I can see some AD issuing a DISCUSS on “why is this encoded in little-endian, where everything else used to be big-endian? Has this been discussed?” To which the chairs would reply, “yes, this has been discussed in CFRG and TLS, and this is our consensus”, and the AD will clear the DISCUSS. It would be entirely weird for it to go any further than that, unless you model ADs as attackers — controlling the network and emitting random DISCUSSes..

Yoav

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 30 Mar 2015 15:32:56 +0000

How will these keys be encoded in X.509 certs?

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Yoav Nir [mailto:[email-masked]]
Sent: Monday, March 30, 2015 11:27 AM
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Cfrg] A way out of the little/big endian dispute?

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Mar 2015 08:41:58 -0700

> How will these keys be encoded in X.509 certs?

No idea: that's for PKIX to decide, but I imagine as BIT STRING, the
same way signatures are encoded now according to RFC 5280.

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 11:32:05 -0500

> sudden we're told to rubber stamp a little endian format just because.

We all know that "network byte order" == big-endian.  But there's no
requirement that we use it as you'll see below.

A search for RFCs defining "network byte order" or telling us to use it
exclusively (or even generally) was not very fruitful (perhaps that's
partly because the new RFC search facility at the RFC-Editor site is
awful, but other search facilities also failed to find much).

I did find this:

https://tools.ietf.org/html/draft-newman-network-byte-order-01

an expired I-D from 1999 with this abstract:

     This memo defines the term "network byte order" and explains why it
     should be used in IETF protocols and media types.

which then died.  Perhaps the datatracker is wrong, and perhaps we
should go look at the IETF mailing list archives for that time period to
see if we can find what happened to this I-D.

I also found that the wikipedia entry for endianness points to RFC1700
as defining network byte order, which it sort of does, but it's been
obsoleted by an RFC that merely says that RFC1700 is replaced by IANA
registries.  I don't think RFC1700 had the force that you seem to be
claiming.  And even if it did, one would still have to get over the "and
so what?" response.

Really, Curve25519 and friends should use little-endian encoding for
their public keys x, y, u, and/or v values.  Full stop.  Because: a)
they already do, and b) it's more efficient on the vast majority of all
hardware in use.  Also: c) this line of argument is grasping at straws.

Finally, I'd say that future *new* curves should also use little-endian
because of (b).  I'd make that a lower-case "should" -- if you really
want, *your* proposed curves can use big-endian.

> fact that little endian is the change.

Even if you were right as to "it", we absolutely could change it --
certainly as to specific items like "public keys for" some cryptosystem.

As it is I don't think we have to go update any RFC about this anyways.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 30 Mar 2015 09:49:01 -0700 (PDT)

> On Mon, Mar 30, 2015 at 7:59 AM, Dan Harkins <[email-masked]> wrote:
[snip]
>> scalarmult in big endian for a good reasonâ€¦ they have nothing to do

  If you truly believed there was no problem then you wouldn't be
arguing to change the wire format for this curve.

> strings of bytes, and SEC1 determines what they mean.

  Wrong! You are expressing a point, as defined by SEC1 (you need
a normative reference for that document in section 7 by the way).

  And if I was to take your draft and implement it I would look at
section 2.3.4 of SEC1 "OctetString-to-EllipticCurvePoint Conversion"
and proceed to 2.2 where I "Convert X to a field element xp of Fq
using the conversion routine specified in Section 2.3.6" which says
to "Convert [the octet string] to an integer _a_ using the conversion
routine specified in Section 2.3.8." And that section is "OctetString-
to-Integer Conversion" and one can see in step 1 that it is quite
obviously big endian. Then my big endian integer becomes xp and
I will proceed to derive yp based on the value of the octet, Y, that
preceded X. Et voila, I have a big endian representation of an
elliptic curve point!

  It is actually a good argument for a single wire format representation
that you not only don't know but apparently don't care about how
information in your draft, necessary for interoperable implementation,
is formatted. The single wire format lets you write your draft in a
way that describes operations done on the points while being blissfully
ignorant of the matter of getting a point from a string of octets. That
is a good thing.

> the relevant standard explaining how those elements are written down.

  No, code, both sensible and insensible, obtains a point on an elliptic
curve in big endian format by doing this sort of octet-string to point
to octet-string conversions. There isn't "the appropriate unpack function
for the group", there is The Appropriate Unpack Function. Period.
Similarly, there is The Appropriate Pack Function, period, which you
call when you want to construct a message containing a point on an
elliptic curve that you will send to another over the ether. What you
are advocating for is the creation of this notion of different (un)pack
functions for different curves. Why? Because this curve was implemented
differently (for reasons that have nothing to do with wire format) and
you cannot abide any questions about it. We must change the way
it is done because this new curve must not be touched.

> Because there are multiple, independent implementations that all use

  The implementation that all the other implementations have expressly
stated they are conforming to (e.g. "The usage is exactly the same…." to
quote one of those other implementations).

  Dan.

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 30 Mar 2015 10:23:51 -0700

> On Mar 30, 2015, at 9:49 AM, Dan Harkins <[email-masked]> wrote:
> 
> 
>>> scalarmult in big endian for a good reasonâ¦ they have nothing to do

I honestly don’t care much about this.  The whole reason we have endian
holy-wars is because the benefits of either endian are vanishingly small
in most cases.  This is especially true in an EC point format, where
conversion is probably less than 0.5% of the code and 0.1% of the time.

Just make a decision — tally the results of the poll even — and be done
with it.  But please make all EC-related serialization fixed-length per curve
this time around.  Stripping out leading zeros is a mistake not to be repeated.

— Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 13:15:12 -0500

> arguing to change the wire format for this curve.

What change?  Are you referring to the assertion you made [in a separate
post] that network byte order is a rule that applies to all protocols?

If so, a) there's no such rule, b) it would be Orwellian to require a
change to a deployed cryptosystem and protocols on account of an
imagined and impermissible change that isn't so.

If you mean that it's a change of representation compared to other ECDH
curves, well, yes, but we already have consensus for that.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 30 Mar 2015 11:39:22 -0700 (PDT)

> post] that network byte order is a rule that applies to all protocols?

  Yes. All protocols except an alleged SSH implementation using
an implementation of curve25519. I can't think of another protocol
that sends bignums over the wire that doesn't use big endian.

> imagined and impermissible change that isn't so.

  a) actually there are several: SEC1, SP 800-56a, X9.42. And they
all use the same data conversion rule that goes from whatever
internal representation you have to big endian for transmission
and back to whatever internal representation the other end has.
All IETF protocols that need to send large public keys around
do it this way.

  b) I think it's time to update Godwin's Law. Orwell? Please. Is this
really like "a boot stomping on a human face forever"? No, I don't
think so.

  The point is that if you want to do something different (make
a special case to have a different wire format for your curve) you
should have a good reason and "that's the way the curve was
originally implemented and we must not entertain thoughts to
make it like conform to existing rules when we standardize it" is
not a good reason.

> curves, well, yes, but we already have consensus for that.

  Well, when determining consensus there is precedence for
considering whether there was any "packing the room" going on.
As a result, consensus is not achieved by merely counting
responses.

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 14:14:08 -0500

> that sends bignums over the wire that doesn't use big endian.

Protocols using PK generally send opaque public keys (e.g., PKIX, which
sends BIT STRING encoded by AlgorithmIdentifier), not bignums.  Others
have pointed this out already.

Be careful as to SSHv2.  It may seem that because the original DH-based
SSHv2 KEX suites sent public keys as 'mpint', therefore all future
DH-like KEX suites must also do so.  But this is not so because the
SSHv2 message types can be and are overloaded (the selected KEX type
dictates overloaded message type form).

With AE-like cryptosystems it's not even clear that the public keys need
always be bignums.  Heck, with ECDH we're already past bignums except
for the x-only representation because with ECC we notionally have public
keys as pairs of [large] numbers.  Plain bignum representations of
public keys would be much too limiting.  For ECC uses where x-only (or
other single-number representations) is insufficient, would you propose
to encode number pairs as a singly bignum?

Besides we've already agreed that ECDH public key representation
(compressed x-only, compressed x and y-sign-bit, ...) is to be chosen on
a per-curve basis.  Why is endianness being discussed at all?  Surely
because it had been controversial earlier, before the chairs polled the
RG specifically as to point representation.  But ISTM that the question
about endianness is mooted by the answer to the question about point
representation.  See more below.

>   a) actually there are several: SEC1, SP 800-56a, X9.42. And they

None of those are Internet standards.  Nor is it the case that Internet
RFCs generally bind protocol developers as to such details.  Normative
language in RFCs applies to IETF processes and to implementations of
protocols specified in RFCs, but there are no normative rules applicable
to protocol _design_ that are as widely scoped as the one you suppose
(just are there are no rules that one must use ASN.1, or XDR, or some
other encoding rules).

> All IETF protocols that need to send large public keys around

PKIX certainly doesn't.  PKIX sends BIT STRING with content encoded per
the assotiated AlgorithmIdentifier.

> really like "a boot stomping on a human face forever"? No, I don't

I was referring to the reversal of meaning of words.  I was not
comparing the outcome you desire to tyranny.  I'm sorry that you read
the wrong meaning; I certainly did not intend to insult or offend you.

> As a result, consensus is not achieved by merely counting

(I am not sent to pack the room.  I'm not "sent" either for that matter.)

I was very much under the impression that the consensus call as to
genericity of point representation yielded a consensus that we don't
need to use a generic point representation for ECDH, with associated
consensus that no one curve's ECDH point representation should be forced
on the others.

If there really is any doubt, then now is a good time for the RG chairs
to make a clear determination of consensus, one that is subject to
appeal.

If I'm right as to that consensus, it follows that the controversy as to
endianness is moot.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Mar 2015 04:22:01 +0100

[snip]
> As a result, consensus is not achieved by merely counting
After reviewing all responses on the mailing list, I don't believe that 
there is any "packing of the room".  Lots of people who responded in 
favour of little-endian for both curves frequently disagree with each 
other in other fora.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 31 Mar 2015 10:24:17 +0000

When we (in an IETF context) needed to refer to network byte order we used W. Richard Stephens TCP/IP illustrated as our reference, as we couldn't find anything better.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: 30 March 2015 17:32
To: Dan Harkins
Cc: [email-masked]
Subject: Re: [Cfrg] A way out of the little/big endian dispute?

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

> sudden we're told to rubber stamp a little endian format just because.

We all know that "network byte order" == big-endian.  But there's no requirement that we use it as you'll see below.

A search for RFCs defining "network byte order" or telling us to use it exclusively (or even generally) was not very fruitful (perhaps that's partly because the new RFC search facility at the RFC-Editor site is awful, but other search facilities also failed to find much).

I did find this:

which then died.  Perhaps the datatracker is wrong, and perhaps we should go look at the IETF mailing list archives for that time period to see if we can find what happened to this I-D.

I also found that the wikipedia entry for endianness points to RFC1700 as defining network byte order, which it sort of does, but it's been obsoleted by an RFC that merely says that RFC1700 is replaced by IANA registries.  I don't think RFC1700 had the force that you seem to be claiming.  And even if it did, one would still have to get over the "and so what?" response.

Really, Curve25519 and friends should use little-endian encoding for their public keys x, y, u, and/or v values.  Full stop.  Because: a) they already do, and b) it's more efficient on the vast majority of all hardware in use.  Also: c) this line of argument is grasping at straws.

Finally, I'd say that future *new* curves should also use little-endian because of (b).  I'd make that a lower-case "should" -- if you really want, *your* proposed curves can use big-endian.

> fact that little endian is the change.

Even if you were right as to "it", we absolutely could change it -- certainly as to specific items like "public keys for" some cryptosystem.

Nico
-- 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Robert Cragie <[email-masked]>
Date: Tue, 31 Mar 2015 11:26:43 +0100

+1. Time to move on.

Robert