Last Call Review of draft-ietf-ace-oscore-profile-11
review-ietf-ace-oscore-profile-11-genart-lc-davies-2020-07-21-00

Request Review of draft-ietf-ace-oscore-profile
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-07-20
Requested 2020-07-06
Authors Francesca Palombini, Ludwig Seitz, Göran Selander, Martin Gunnarsson
Draft last updated 2020-07-21
Completed reviews Genart Last Call review of -11 by Elwyn Davies (diff)
Opsdir Last Call review of -11 by Linda Dunbar (diff)
Assignment Reviewer Elwyn Davies 
State Completed
Review review-ietf-ace-oscore-profile-11-genart-lc-davies-2020-07-21
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/dYccaGQYJbx3AL6kW4MjsLcfUfA
Reviewed rev. 11 (document currently at 13)
Review result Almost Ready
Review completed: 2020-07-21

Review
review-ietf-ace-oscore-profile-11-genart-lc-davies-2020-07-21

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-oscore-profile-11
Reviewer: Elwyn Davies
Review Date: 2020-07-21
IETF LC End Date: 2020-07-20
IESG Telechat date: Not scheduled for a telechat

Summary:  Almost ready.  There is one minor issue that needs sorting out and a fair number of nits.  Overall I have to say that I found it difficult to keep clear in my mind what messages were fully encrypted and which ones were sent en clair and which are in some intermediate class.  The authors might wish to go back over the document from the point of a naive reader to ensure that it is clear for implementers. 

Major issues:
None

Minor issues:
s2, para 5:  Where does the 'input salt' come from?  The term is not used anywhere else in this document and  isn't defined or mentioned in either dreft-ace-oauth-authz or RFC 8613.

Nits/editorial comments:
s1:  Need to expand CoAP on first use.

s1: Need to expand CBOR on first use.

s1.2, CDDL:  It would useful to mention that the predefined type names from CDDL, especially bstr for byte strings and tstr for text strings,  are used extensively in the document. 

s2, para 1: s/overview on how/overview of how/

s2, para 1: s/as well as OSCORE setup/as well as the OSCORE setup/

s2, para 2: s/that's/that is/

s2, para 8: Need to expand AEAD on first use.

s2 and Figure 1:  It would be helpful to the reader if Figure 1 and its descriptive paragraph was placed closer to the beginning of s2.  Otherwise things like Client C' need more explanation to point the reader at the figure.

s2, para 3:

This says:
To determine the AS in charge of a resource hosted at the RS, the client C MAY send an initial Unauthorized Resource Request message to the RS. The RS then denies the request and sends the address of its AS back to the client C as specified in section 5.1 of [I-D.ietf-ace-oauth-authz]. The access token request and response MUST be confidentiality-protected and ensure authenticity

I found the combination of the Unauthorized Requst and the confidentiality-protected etc confusing.  If the last sentence does apply to the Unuthorized Request it would be helpful to make it clear that this is not just a generic statement but does apply to the Unauthorized Request as well.
 
Figure1:  For consistency the first line should say Unauthorized Rsource Request.  I would also suggest explaining the mapping between what is said in the text and the terms 'Ceation Hints' and 'Access Information' used in the figure.

s3.1, para after Figure 2:  The term 'audience' appears in this paragraph without any context indicating what it means .  Later in s3.2 it appears that audience is associated with CBOR web tokens (RFC 8392).  But it may also might also be 
realted to draft-oauth-token exchange.  The appropriate reference ahould be added and should be explained in s3.1. 

Figure 3:  Should IdContext be ContextId?  ContextId is used evrywhere else.

s3.2: Expand HKDF on first use ( in second set of bullets).

s3.2, para after 2nd set of bullets:  I think the four instances of 'may'  ought to be 'MAY'.

s3.2.1:  It would be helpful to provide references to the online versions of the  IANA registries (3 places).

s4.2, para 1:   A foward reference to s5 where the comunication mechanisms needed for introspection are described.

s4.1, para 2: s/from what described/from what is described/

s4.2, para 5: s/that's/that is/

s4.2, last para; s/This simplifies for the RS track/This simplies the process needed by the RS to keep track/ 

s8, para 6: s/tasked of/tasked with/

s9.3:  I don't think the Value Type for nonce is 'IESG'! lol