Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
RFC 8731

Note: This ballot was opened for revision 10 and is now closed.

Benjamin Kaduk Yes

(Ignas Bagdonas) No Objection

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Roman Danyliw No Objection

Comment (2019-09-05)
No email
send info
Thank you for addressing my COMMENTs.

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-09-03 for -10)
Mirja beat me to it with the questions re: the additional Copyright text -- I'd *thought* I'd seen a reply to that mail, but cannot seem to find it at the moment..

"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. "
Fair enough -- but would it be possible to point at where people can go find out what the "appropriate SSH protocol error" is?

(Mirja Kühlewind) (was Discuss) No Objection

Comment (2019-09-04 for -11)
Thanks for addressing my discuss and comment!

(Barry Leiba) No Objection

Comment (2019-09-03 for -11)
No email
send info
Nothing to add but agreement with the ballots already in.

(Alexey Melnikov) No Objection

Comment (2019-08-28 for -10)
The following text in Section 1:

   At the time of writing this specification, high-quality free
   implementations of Curve25519 has been in deployed use for several
   years, while Curve448 implementations are slowly appearing, so it is
   accepted that adoption of Curve448 would be slower.

would not age well once the RFC is published. I suggest this is moved from the draft to the shepherding write-up.

Also, SHA-256 and SHA-512 need to be normative references.

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2019-09-03 for -11)
Thanks for the work on documenting this key exchange method.

I'm a little surprised that there is no discussion of deployment considerations for deploying "curve25519-sha256" into an environment in which "" is already well-established (as described in the introduction), or of sunsetting the vendor-specific version. Some advice on which algorithms to offer and which ones to accept would probably be worthwhile, especially if there is any long-term hope of retiring the "" designator in favor of the standard one.

Martin Vigoureux No Objection

Comment (2019-09-05 for -11)
No email
send info
s/This document provide/This document provides/

Éric Vyncke (was Discuss) No Objection

Comment (2019-09-04 for -11)
Thank you for having fixed my DISCUSS and COMMENTs

(Magnus Westerlund) No Objection