|
Hi,
Thank you Russ and Denis for the response. Please see my personal comments and responses inline. I hope It will help to move the draft forward, and let me know if additional
information is necessary. Overall, I believe the discussion is how wise it is to use a designation different from the one defined by NIST. Here, NIST indicates the algorithm version for version 1 and
3 while not for version 2. I think we should try not to use different designations as much as possible as it leaves place for doubts whereas the two designations actually designates the same thing. I
hope I am clear. Note that mnemonic strings may use any conventions as long as their definition is non ambiguous. I also noted that mnemonic strings registered at the IANA were not always consistent
even within a given protocol. TLS seems however consistent. Yours,
Daniel
From: denis bider [mailto:denisbider.ietf@xxxxxxxxx]
Hello Russ, thank you for the review. Comments: > I think that a better title for this document would be: > Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH) I can make this change, but I should note this is not universally agreed on. In a previous specification, which became RFC 6668: ... the original draft called for e.g. "hmac-sha256", but there were immediate concerns about ambiguity which led to "hmac-sha2-256" and "hmac-sha2-512" being specified. <mglt> The current title is : “Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)” The title specifies the version associated to SHA. It may sounds clarifying in some context, but on the other hand, it requires also the reader to induce that SHA-2 256 is
a designation – maybe more logic – to what NIST designates as SHA-256. I am thus incline to re-use as much as possible the NIST designation to avoid interpretation from the reader.
My understanding is that hmac-sha2-256 is using SHA-256 and that hmac-sha2-512 is using SHA-512. It happens that in this case the designation of the algorithm includes the
message digest size. Am I correct ? </mglt> > The current wording seems to include SHA-224 and SHA-384, > and that is not the intent of the author. True, but in this case as well, I point out RFC 6668, where we have the title: "SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol" ... even though the document only specifies "hmac-sha2-256" and "hmac-sha2-512". It appears to me that it may not be necessary for a document to specify use of all versions of SHA-2, in order to be accurately described as specifying the use of SHA-2 in a context. <mglt>
I agree that we do not need to specify all hashing functions defined by FIPS-180. However, I believe that Russ suggests that
“” This memo updates RFC 4252 and RFC 4253 to define new public key algorithms allowing for interoperable use of existing and new RSA keys with SHA-2 hashing. “”” Could be replaced by
“”” This memo updates RFC 4252 and RFC 4253 to define new public key algorithms allowing for interoperable use of existing and new RSA keys with SHA-256 and SHA-512. “”” I think that is more accurate.
</mglt> > I did not propose changing the strings in case people have > already implemented against this specification. If no one > has implemented yet, then I would change those too. This intuition is correct. It has been widely implemented and is deployed on, very possibly, millions of systems. One can launch an off-the-shelf Amazon instance that has a long-term-support edition of Ubuntu
with a version of OpenSSH that implements this. > Section 5.1 should be expanded to say that following the NIST > advice on key sizes and SHA-1 outside the US Government is > prudent. I can do this. As instructed, I await instructions from the document shepherd. denis On Fri, Sep 1, 2017 at 8:55 AM, Russ Housley <housley@xxxxxxxxxxxx> wrote:
|