Re: [Curdle] Roman Danyliw's No Objection on draft-ietf-curdle-ssh-curves-11: (with COMMENT)

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

Hi Roman,

Roman Danyliw via Datatracker <[e-mail]> writes:

> (1) Section 1.  Please provide informative reference to libssh and OpenSSH.

Will add both

    ...elided...
    libssh <xref target="libssh"/> and OpenSSH <xref target="OpenSSH"/>.
    ...elided...


     <reference
         anchor="libssh"
         target="https://www.libssh.org/">
       <front>
         <title>The SSH Library</title>
         <author>
           <organization>libssh</organization>
         </author>
         <date month="September" year="2019"/>
       </front>
     </reference>

     <reference
         anchor="OpenSSH"
         target="https://www.openssh.com/">
       <front>
         <title>The OpenSSH Project</title>
         <author>
           <organization>OpenSSH group of OpenBSD</organization>
         </author>
         <date month="September" year="2019"/>
       </front>
     </reference>

I am not sure these references are all that helpful...?

> (2) Section 5. Per the second paragraph of this section, I would recommend
> being clearer on the differences and similarities of both algorithms so
> implementers understand the tradeoffs.  Specifically:
> 
> -- Curve25519 is “strong” (Section 1 says ~128 bits) and Curve448 “hasn't
> received the same cryptographic review” – these seem like unequal statements.

Okay.

> -- Curve 25519 makes the claims of being “efficient on a wide range of
> architecture” and “better implementations properties compared to traditional
> elliptical curves”.  Curve448 “is similar … and is slower”.  So is it
> inefficient across architectures? Worst implementation properties?  Can
> anything be said to qualify “slower”?

I believe it is slower because it is processing more bits of key and
uses a larger hash (SHA-256 is faster than SHA-512 on i386 hardware and
about the same in X86_64 hardware due to native word lengths).

> -- I recommend moving the guidance on what is recommend and why to be
> in this section so the rational is in one place (rather than also
> being in Section 1, “This document provide Curve25519 as the preferred
> choice, …”)

I have removed the last paragraph of section 1 (Introduction).

I have updated section 5 (Security Considerations) as follows:

      <t>
        The security considerations of <xref target="RFC4251"/>, <xref
        target="RFC5656"/>, and <xref target="RFC7748"/> are
        inherited.
      </t>

      <t>
        Curve25519 with SHA-256 provides strong (~128 bits) 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
        provides stronger (~224 bits) security with similar
        implementation properties, but has not received the same
        cryptographic review as Curve25519, and is slower (larger key
        material and larger secure hash algorithm), but it is provided
        as a hedge to combat unforeseen analytical advances against
        Curve25519 and SHA-256 due to the larger number of security
        bits.
      </t>

      <t>
        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 the most significant bytes are
        zero.  For backwards compatibility reasons it was decided not
        to address this potential problem.
      </t>

      <t>
        This document provides "curve25519-sha256" as the preferred
        choice, but suggests that the "curve448-sha512" is implemented
        to provide more than 128 bits of security strength should that
        become a requirement.
      </t>


> (3) Appendix A: As other ballots have noted, is this section needed?

Appendix A has been removed.

> (4) Editorial Nits:
> -- Section 3.  s/chapter 4/section 4/g

Fixed.

> -- Section 3.1. The text “… passed to the ECDH code in SSH that …”
> reads like a given implementation is being discussed. Perhaps “passed
> to the ECDH function” (or ECDH algorithm).

Fixed. Using: s/ECDH code/ECDH function/ 

> -- Section 1. Per “The Curve448 key exchange method is similar but
> uses SHA-512 [RFC6234] to further separate it from the Curve25519
> alternative.”, I recommend dropping the ending clause of “to further
> separate it from the Curve22519 alternative”. The subsequent text (in
> the Security Considerations) appear to already cover that it is an
> alternative.

Adopted.

	-- Mark