RE: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10

Daniel Migault <daniel.migault@ericsson.com> Tue, 10 October 2017 17:02 UTC

Return-Path: <daniel.migault@ericsson.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD7413460A; Tue, 10 Oct 2017 10:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVWNHAwdTkqK; Tue, 10 Oct 2017 10:02:49 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA8A133321; Tue, 10 Oct 2017 09:56:11 -0700 (PDT)
X-AuditID: c618062d-b7bff70000004f0a-5b-59dd149fe080
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id CD.42.20234.F941DD95; Tue, 10 Oct 2017 20:42:40 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0352.000; Tue, 10 Oct 2017 12:56:10 -0400
From: Daniel Migault <daniel.migault@ericsson.com>
To: denis bider <denisbider.ietf@gmail.com>, Russ Housley <housley@vigilsec.com>
CC: "gen-art@ietf.org" <gen-art@ietf.org>, curdle <curdle@ietf.org>, "draft-ietf-curdle-rsa-sha2.all@ietf.org" <draft-ietf-curdle-rsa-sha2.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10
Thread-Topic: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10
Thread-Index: AQHTIyoFfx+QsTqog06rd1NPRiLpw6Khh3WAgDvfHsA=
Date: Tue, 10 Oct 2017 16:56:09 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CF2354@eusaamb107.ericsson.se>
References: <150427414878.3237.4575033946525642940@ietfa.amsl.com> <CADPMZDBhLQ3ztEoL_Eg_hnZFihCTFpsachjZYgSr_gRO4WbiZw@mail.gmail.com>
In-Reply-To: <CADPMZDBhLQ3ztEoL_Eg_hnZFihCTFpsachjZYgSr_gRO4WbiZw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CF2354eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyuXRPrO4CkbuRBo1XBSy2LpzFbHH83Fxm i71bL7JYXH31mcXi1Yub7BbPNs5ncWDz2DnrLrvHkiU/mTxW3fnCGsAcxWWTkpqTWZZapG+X wJWxuWUGW8GMf4wVx14+Y29gPPCdsYuRk0NCwERi3ZM/7F2MXBxCAkcZJR7vvs0I4SxnlNi7 5DszSBWbgJFE26F+dhBbRCBIovXOFhaQImaBvYwSN2fcZgJJCAsESLxfvYINoihQYtXEnVC2 lcTd9glgzSwCqhJN3z+BDeUV8JU4vOoPK8S2TkaJ7+uPgQ3iBGre8XUzC4jNKCAm8f3UGrA4 s4C4xK0n85kg7haQWLLnPDOELSrx8vE/VghbSeLj7/nsEPX5EvPfNbJALBOUODnzCcsERpFZ SEbNQlI2C0nZLEYOoLimxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyFFaXJCTm25ksIkR GHfHJNh0dzDen+55iFGAg1GJh9fs451IIdbEsuLK3EOMEhzMSiK8rj+AQrwpiZVVqUX58UWl OanFhxilOViUxHknnL8QISSQnliSmp2aWpBaBJNl4uCUamCUf3bj24pIHrMy9vjSvc/0zG/x B9xsWGR398kXRaGfb4Nf/lhSX9DGeF/0krbezDiVEPn1F1/HMOklqx+6szNo6oR+q/hH79b0 fVkcFbdv37WfaT9YY9fsEnxzVMfJ2fjB8vkZ7gypE+69m6ryb23zn3nzfL4fYd1SLTArmX/R XbGDzVeW1B5wVWIpzkg01GIuKk4EAPRTiz63AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/91QIltSlYjQusCXBr0mdUUXAXUM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 17:02:56 -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:denisbider.ietf@gmail.com]
Sent: Saturday, September 02, 2017 4:28 AM
To: Russ Housley <housley@vigilsec.com>
Cc: gen-art@ietf.org; curdle <curdle@ietf.org>; draft-ietf-curdle-rsa-sha2.all@ietf.org; ietf@ietf.org
Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-rsa-sha2-10

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:

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,
> 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@vigilsec.com<mailto:housley@vigilsec.com>> 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


_______________________________________________
Curdle mailing list
Curdle@ietf.org<mailto:Curdle@ietf.org>
https://www.ietf.org/mailman/listinfo/curdle