Subject: Re: [Curdle] [Gen-art] Genart last call review of draft-ietf-curdle-rsa-sha2-10

From: Alissa Cooper <[email-masked]>
Date: Tue, 10 Oct 2017 10:33:28 -0400

Russ, thanks for your review. I have entered a No Objection ballot that links to your review since it looks like your first two comments have not quite been resolved yet.

Alissa

> On Sep 1, 2017, at 9:55 AM, Russ Housley <[email-masked]> wrote:
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-curdle-rsa-sha2-10
> Reviewer: Russ Housley
> Review Date: 2017-09-01
> IETF LC End Date: 2017-09-11
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> Major Concerns: None
> 
> 
> Minor Concerns:
> 
> 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)
> 
> These are two of the hash function in the SHA2 family, and there is no
> ambiguity about them being part of the SHA3 family.  Similarly, I think
> that the Abstract and Section 1 should explicitly names these two hash
> functions.  The current wording seems to include SHA-224 and SHA-384,
> and that is not the intent of the author.
> 
> In Section 3, I suggest:
>   s/using SHA-2 [SHS] as hash./using SHA-256 or SHA-512 [SHS] as hash./
>   s/the hash used is SHA-2 256./the hash used is SHA-256./
>   s/the hash used is SHA-2 512./the hash used is SHA-512./
> 
> Note:  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.
> 
> 
> 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.
> 
> 
> Nits: None
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Daniel Migault <[email-masked]>
Date: Tue, 10 Oct 2017 16:56:09 +0000

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:[email-masked]]
Sent: Saturday, September 02, 2017 4:28 AM
To: Russ Housley <[email-masked]>
Cc: [email-masked]; curdle <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10

Hello Russ,

> 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:

https://www.ietf.org/rfc/rfc6668.txt

... 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,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Russ Housley
Review result: Almost Ready

Summary: Almost Ready

Major Concerns: None

Minor Concerns:

In Section 3, I suggest:

Nits: None

_______________________________________________
Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle