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

Summary: Has enough positions to pass.

Kathleen Moriarty Yes

Comment (2017-10-11 for -11)
Thanks for addressing the SecDir review comments.
https://mailarchive.ietf.org/arch/msg/secdir/ObNBH1VK1aPmdid3StYKLooa4Ls

Eric Rescorla Yes

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2017-10-10 for -11)
[EXT-INFO] needs to be a normative reference, since it's part of a SHOULD level normative requirement.

Benoit Claise No Objection

Alissa Cooper No Objection

Comment (2017-10-10 for -11)
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.

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja K├╝hlewind No Objection

Alexey Melnikov No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2017-10-10 for -11)
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.

Alia Atlas No Record

Terry Manderson No Record