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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 04 Sep 2019 11:01:00 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-curdle-ssh-curves-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

(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.

-- 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 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, …”)

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

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

-- 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).

-- 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.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 4 Sep 2019 17:16:46 -0700

Hi Roman,

> (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...?

> -- Curve25519 is “strong” (Section 1 says ~128 bits) and Curve448 “hasn't

Okay.

> 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.

> -- 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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 5 Sep 2019 07:58:39 -0700

Hi Roman,

I have pushed the -12 revision of

to address your comments.

	-- Mark

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 5 Sep 2019 15:04:53 +0000

Hi Mark!

Thanks for this revision and the quick turn-around.  The changes address all of my feedback.

Roman

> -----Original Message-----
> From: Mark D. Baushke [mailto:[email-masked]]
> Sent: Thursday, September 05, 2019 10:59 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; Daniel
> Migault <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-curdle-ssh-curves-
> 11: (with COMMENT)
> 
> Hi Roman,
>