Re: [Ace] [Last-Call] Genart telechat review of draft-ietf-ace-oscore-profile-17

Lars Eggert <lars@eggert.org> Thu, 25 March 2021 11:30 UTC

Return-Path: <lars@eggert.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886D53A1E68; Thu, 25 Mar 2021 04:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 fsueQHCwv-5l; Thu, 25 Mar 2021 04:30:15 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD183A1E66; Thu, 25 Mar 2021 04:30:12 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:cd46:2bbf:5755:8854] (unknown [IPv6:2a00:ac00:4000:400:cd46:2bbf:5755:8854]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id B892360030E; Thu, 25 Mar 2021 13:29:53 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1616671793; bh=Lg8zQGDywkZ7Ngt4rhz4UpHwHdj72poCYgzDB6htgNs=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=xshdy22vB28h0CSZuIXjX+Qq2wq55cRTWhvpypmnsfzPPjhAtZaG4ymHQ93FA8nyU IaiXb8v81K4+XEpi4R129Gl+lJ+LJTXHuK3Lc+FEJbxW/MiEvO9ydA/gEAz9w88gm7 jK8NQML6aHE77QlGm4tpIfH40B9lUtuCvfPrUVhU=
From: Lars Eggert <lars@eggert.org>
Message-Id: <B29B8F18-4828-41ED-AB16-FE150339D7DB@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_4BA89FF7-58BB-42A3-ACC3-2EBA14DF7161"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Thu, 25 Mar 2021 13:29:53 +0200
In-Reply-To: <161653858008.2324.11904671400153326745@ietfa.amsl.com>
Cc: General Area Review Team <gen-art@ietf.org>, Last Call <last-call@ietf.org>, draft-ietf-ace-oscore-profile.all@ietf.org, ace@ietf.org
To: Elwyn Davies <elwynd@dial.pipex.com>
References: <161653858008.2324.11904671400153326745@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-MailScanner-ID: B892360030E.A2D98
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/S50XulLxmV01Q5AWwg3wRSEVqVw>
Subject: Re: [Ace] [Last-Call] Genart telechat review of draft-ietf-ace-oscore-profile-17
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 11:30:21 -0000

Elwyn, thank you for your review. I have entered a No Objection ballot for this document.

Lars

On 2021-3-24, at 0:29, Elwyn Davies via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Elwyn Davies
> Review result: Ready with Nits
> 
> 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-ace-oscore-profile-17
> Reviewer: Elwyn Davies
> Review Date: 2021-03-23
> IETF LC End Date: 2020-07-20
> IESG Telechat date: 2021-03-25
> 
> Summary:
> Ready with nits.  A very great improvement on the previously reviewed version.
> Thanks.
> 
> Major issues:
> None
> 
> Minor issues:
> 
> Would it be useful to provide some advice on the length of salts and IDs to go
> with the advice on length of nonces?  There is some in s3.3 of RFC 8613 but
> some other reference might be helpful, maybe placed in s3.2.1. and/or s4.
> 
> Nits/editorial comments:
> 
> General: The RFC Editor conforms rigorously to American practice and allows
> only the use of double quote marks (") in the text when marking strings as
> quotations and such like.  The document makes extensive but not totally
> consistent, use of single quotes to flag up field names and such like (e.g.,
> 'nonce1').  In practice these are unnecessary, but may be replaced by the RFC
> Editor if left in place.  Personally. I think most of them can be removed. NB
> this does not affect CBOR items such as h'1645.
> 
> General: There are lots of usages of 'CBOR diagnostic notation without the tag
> and value abbreviations'.  An abbreviation would reduce the verbiage.
> 
> General: It is slightly confusing to have Nonce 1/N1/nonce1 and Nonce
> 2/N2/nonce2 used in the document.  Am I right in thinking Nonce 1 and N1 are
> the same with nonce1  being the name of the JSON/CBOR parameter used to carry
> the value?  A few words of clarrification would help.
> 
> Abstract/s1:  It would be useful to introduce the name of the profile
> (coap_oscore) up front.  It rather sneaks out in s3.
> 
> s1, para 2: Need to expand CBOR on first use.
> 
> s2, end of para 3: s/as well/instead/? or s/as well/alternatively/.
> 
> s2, para 7 and s6, bullet 2: s/e.g. expiration./for example, expiration./
> 
> s3.1, para 3 and last para: s/reported/shown/
> 
> s3.1, Figure 2 and Figure 3: Appendix F.3 of draft-ietf-ace-oauth-authz reports
> that req_aud was replaced by audence at version 19 of the document.
> 
> s3.2, second set of bullets:  Need to expand HMAC and HKDF on first use (not
> well-known in RFC Editor list).  It would also be useful to put a pointer to
> section 11.1 of RFC 8152 here to indicate the allowed HKDF algorithms.
> 
> s3.2, 2nd para after 2nd set of bullets: s/The applications needs/The
> application needs/
> 
> s3.2, 3rd para after 2nd set of bullets: s/parameeter/parameter/
> 
> s3.2, 4th para after 2nd set of bullets: s/the use of CBOR web token/the use of
> a CBOR web token/
> 
> s3.2.1:
> OLD:
> IANA "OSCORE Security Context Parameters" registry (Section 9.4), defined for
> extensibility, and is specified below. NEW: IANA "OSCORE Security Context
> Parameters" registry (Section 9.4), defined for extensibility, and the initial
> set of parameters defined in this document is specified below. END
> 
> s3.2.1, below Figure 9: Expand CDDL.
> 
> s4.1, para 1 and s4.2, para 2: s/RECOMMENDS to use/RECOMMENDS using/
> 
> s4.1, para 1 and s4.2. para 2: s/as nonce's value/as the nonce's value/
> 
> s4.1, para 7: s/renew/update/  [renew implies the same identifiers are used -
> which is already specified!]
> 
> s4.1, last para and s4.3, last para: Does /authz-info have some special meaning?
> 
> s4.3, para 1: s/ Once receiving the 2.01 (Created) response from the RS/ Once
> the 2.01 (Created) response is received from the RS/
> 
> s4.3, Figure 12:  I assume the Master Salt is supposed to be a CBOR indefinite
> length string encoding (it doesn't say so) as it it consists of the
> concatenated CBOR strings of its component byte strings.  It would be strictly
> correct to start it with 0x5f and end with (0x)ff I would have thought. Be that
> as it may, I do not understand why the document is concerned with either CBOR
> or JSON/base64 encodings of the master salt.  It may be that I am missing
> something, but I didn't think that the master salt was ever put in a protocol
> message as such (deliberately), but only as one or two of its components such
> that it could be privately constructed at both endpoints once the three
> components had been shared, and was just the concatenation of the data bytes of
> the 3 components rather than involving their lengths.
> 
> s6. last para: s/observation/observations/
> 
> s7, para 3: s/RS pass/RS passes/
> 
> s9: It is now usual to give the URLs for the various existing registries as
> normative references.
> 
> s9.4: I am not aware that a single registry can have different
> review/specfication requirements for portions of its parameter space.  Is it
> seriously expected that there will be significant numbers of requests for
> values in this registry?  My instinct would be to go for specification required
> and advise allocation according to the orign and type of the specification.
> 
> 
> 
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call