Re: [Curdle] Second AD Review: draft-ietf-curdle-ssh-curves.

["Mark D. Baushke" <[e-mail]>]

Hi Ron & Ben,

Modulo the date stamp changes and the line break changes, here is what
the modified text looks like after trying to address the comments you
both made.

Let me know if I captured your intended changes correctly or not.

I can either upload a new version, or just roll these changes into the
next version after addressing any other comments during LC.

	Thanks,
	-- Mark

--- draft-ietf-curdle-ssh-curves-09.txt	2019-08-03 14:44:28.000000000 -0700
+++ draft-ietf-curdle-ssh-curves-10.txt	2019-08-12 21:55:24.000000000 -0700
@@ -133,21 +133,25 @@
    are generated as described therein.  Public keys are defined as
    strings of 32 bytes for Curve25519 and 56 bytes for Curve448.
 
-   Key-agreement schemes Curve25519 and Curve448 perform the Diffie-
-   Helman protocol using the functions X25519 and X448, respectively.
-   Implementations SHOULD compute these functions using the algorithms
-   described in [RFC7748].  When they do so, 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].
-   Alternative implementations of these functions SHOULD abort when
-   either input forces the shared secret to one of a small set of
-   values, as discussed in Section 7 of [RFC7748].  Clients and servers
-   MUST fail the key exchange if the length of the received public keys
-   are not the expected lengths.  No further validation is required
-   beyond what is discussed in [RFC7748].  The derived shared secret is
-   32 bytes when Curve25519 is used and 56 bytes when Curve448 is used.
-   The encodings of all values are defined in [RFC7748].  The hash used
-   is SHA-256 for Curve25519 and SHA-512 for Curve448.
+   Key-agreement schemes "curve25519-sha256" and "curve448-sha512"
+   perform the Diffie-Helman protocol using the functions X25519 and
+   X448, respectively.  Implementations SHOULD compute these functions
+   using the algorithms described in [RFC7748].  When they do so,
+   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].  Alternative implementations of these
+   functions SHOULD abort when either input forces the shared secret to
+   one of a small set of values, as discussed in Section 7 of [RFC7748].
+   Clients and servers MUST fail the key exchange if the length of the
+   received public keys are not the expected lengths.  An abort for
+   these purposes is defined as a disconnect of the session with an
+   appropriate SSH "protocol error" for the fault provided to or by the
+   client.  No further validation is required beyond what is discussed
+   in [RFC7748].  The derived shared secret is 32 bytes when
+   "curve25519-sha256" is used and 56 bytes when "curve448-sha512" is
+   used.  The encodings of all values are defined in [RFC7748].  The
+   hash used is SHA-256 for "curve25519-sha256" and SHA-512 for
+   "curve448-sha512".
 
 3.1.  Shared Secret Encoding
 
@@ -158,9 +162,9 @@
 
    The shared secret, K, is defined in [RFC4253] and [RFC5656] as an
    integer encoded as a multiple precision integer (mpint).
-   Curve25519/448 outputs a binary string X, which is the 32 or 56 byte
-   point obtained by scalar multiplication of the other side's public
-   key and the local private key scalar.  The 32 or 56 bytes of X are
+   Curve25519/448 outputs a binary string X, which is the 32 or 56 byte
+   point obtained by scalar multiplication of the 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 octets as an unsigned fixed-
    length integer encoded in network byte order.
 
@@ -215,8 +218,8 @@
    The way the derived binary secret string is encoded into a mpint
    before it is hashed (i.e., adding or removing zero-bytes for
    encoding) raises the potential for a side-channel attack which could
-   determine the length of what is hashed.  This would leak the most
-   significant bit of the derived secret, and/or allow detection of when
+   determine the length of what is hashed.  This would leak the most
+   significant bit of the derived secret, and/or allow detection of when
    the most significant bytes are zero.  For backwards compatibility
    reasons it was decided not to address this potential problem.