Subject: [Curdle] AD Review of: draft-ietf-curdle-ssh-curves-04.txt

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 May 2017 12:33:00 -0700

Document: draft-ietf-curdle-ssh-curves-04.txt

TECHNICAL
S 2.

   The methods are based on Curve25519 and Curve448 scalar
   multiplication, as described in [RFC7748].  Private and public keys
   are generated as described therein.  Public keys are defined as
   strings of 32 bytes for Curve25519 and 56 bytes for Curve448.
   Clients and servers MUST fail the key exchange if the length of the
   received public keys are not the expected lengths, or if the derived
   shared secret only consists of zero bits.  No further validation is
   required beyond what is discussed in [RFC7748].

Is any other validation specified? Maybe I'm missing it, but I don't
see any.

S 2.1. IMPORTANT:
   other side’s public key and the local private key scalar.  The 32 or
   56 bytes of X are converted into K by interpreting the bytes as an
   unsigned fixed-length integer encoded in network byte order.  This
   conversion follows the normal "mpint" process as described in section
   5 of [RFC4251].

It appears you are specifying the opposite encoding from RFC 7748 which
says:

   or GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in
   little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... +

First, I want to confirm that this is in fact true and that I'm not
missing something. Second, if it's not true, this needs to be called out
in big letters.

EDITORIAL
   Curve25519 provide strong security and is efficient on a wide range
   of architectures, and has properties that allows better
   implementation properties compared to traditional elliptic curves.
   Curve448 with SHA-512 is similar, but have not received the same

has not received

-Ekr

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 5 May 2017 14:16:39 -0700

Hi Eric,

> Is any other validation specified? Maybe I'm missing it, but I don't

Hmmm... When I read it, I was under the impression that this was
referencing the concept of batched verification via the referenced via
the [goldilocks] paper http://eprint.iacr.org/2015/625.pdf reference in
RFC 7748. It is possible that my reading is flawed.

I am willing to consider alterations to the text to make it better if
you have something in particular to propose.

> missing something. Second, if it's not true, this needs to be called out

I regret that I did not do anything to implement Curdle448 myself.

I suspect that only Aris or Simon will be able to be authoritative on
this set of paragraphs.

>    Curve448 with SHA-512 is similar, but have not received the same

Good catch, I have incorporated this change into my copy of the
document. I will publish an update after more folks have commented on
the points you raised.

	-- Mark

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 May 2017 14:22:57 -0700

> you have something in particular to propose.

Hmm.. Mostly, I'm just trying to figure out what this document is saying,
because it just doesn't seem clear. What is it you think people should
do?

With that said, TLS just specifies:

   For X25519 and X448, implementations SHOULD use the approach
   specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748].  If implementers use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748].

-Ekr

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 11 May 2017 12:17:30 -0700

Hi Eric,

The updated draft-ietf-curdle-ssh-curves-05.txt should address all of
your concerns.

I also ran throug the idnits tool (URL:
https://tools.ietf.org/tools/idnits/) and moved informatonal RFCs:
RFC6234 and RFC7748 from "Normative References" to "Informative
References" to remove the last two errors.

I hope this edition is sufficient to pass the AD Review.

Please let me know of any remaining issues with the document.

	Thank you,
	-- Mark