Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
draft-ietf-curdle-rsa-sha2-12

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

Alvaro Retana No Objection

Warren Kumari No Objection

(Eric Rescorla; former steering group member) Yes

(Kathleen Moriarty; former steering group member) Yes

Thanks for addressing the SecDir review comments.
https://mailarchive.ietf.org/arch/msg/secdir/ObNBH1VK1aPmdid3StYKLooa4Ls

(Adam Roach; former steering group member) No Objection

Section 3.2:
  The signature field, if present, encodes a signature using an
  algorithm name that MUST match the SSH authentication request - either
  "rsa-sha2-256", or "rsa-sha2-512".

It might be that I'm not familiar enough with SSH to know what recipients do when receiving unexpected values and the the proper behavior here would be obvious to implementors. If that's not the case, I would think that additional text here telling recipients what to do in the case of a mismatch would be helpful.

The reference [EXT-INFO] needs to be normative rather than informative, as it is part of a normative behavior described in this document.

Both section 1 and Section 5.1 describe NIST recommendations regarding key length, while not endorsing them (normatively or otherwise). This strikes me as notable, given that the NIST recommendations regarding SHA-1 seem to form part of the rationale for its replacement. Is the lack of endorsing NIST-recommended key lengths intentional?



Nits:

RFC6979 is in the references section, but does not appear to be referenced.

One of the lines in the Acknowledgements section is too long.

(Alexey Melnikov; former steering group member) No Objection

(Alissa Cooper; former steering group member) No Objection

There are a few outstanding comments from the Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-curdle-rsa-sha2-10-genart-lc-housley-2017-09-01/

I personally do not have strong feelings about the title and the text in Section 3.1 but the review comments should be resolved by the author/WG.

(Ben Campbell; former steering group member) No Objection

[EXT-INFO] needs to be a normative reference, since it's part of a SHOULD level normative requirement.

(Benoît Claise; former steering group member) No Objection

(Deborah Brungard; former steering group member) No Objection

(Mirja Kühlewind; former steering group member) No Objection

(Spencer Dawkins; former steering group member) No Objection

(Suresh Krishnan; former steering group member) No Objection