Skip to main content

Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
draft-ietf-curdle-ssh-curves-12

Yes

(Benjamin Kaduk)

No Objection

(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Suresh Krishnan)

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

Roman Danyliw
No Objection
Comment (2019-09-05) Sent for earlier
Thank you for addressing my COMMENTs.
Warren Kumari
No Objection
Comment (2019-09-03 for -10) Sent
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..

Also:
"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?
Éric Vyncke
(was Discuss) No Objection
Comment (2019-09-04 for -11) Sent
Thank you for having fixed my DISCUSS and COMMENTs
Benjamin Kaduk Former IESG member
Yes
Yes (for -10) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2019-09-03 for -11) Sent
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 "curve25519-sha256@libssh.org" 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 "curve25519-sha256@libssh.org" designator in favor of the standard one.
Alexey Melnikov Former IESG member
No Objection
No Objection (2019-08-28 for -10) Sent
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.
Alissa Cooper Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-09-03 for -11) Not sent
Nothing to add but agreement with the ballots already in.
Deborah Brungard Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (2019-09-05 for -11) Not sent
s/This document provide/This document provides/
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2019-09-04 for -11) Sent
Thanks for addressing my discuss and comment!
Suresh Krishnan Former IESG member
No Objection
No Objection (for -11) Not sent