IETF Last Call Review of draft-ietf-core-oscore-groupcomm-26
review-ietf-core-oscore-groupcomm-26-genart-lc-kyzivat-2025-07-23-00

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-core-oscore-groupcomm-26
Reviewer: Paul Kyzivat
Review Date: 2025-07-23
IETF LC End Date: 2025-07-29
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

Comment:

This document notes "Readers are expected to be familiar with" (a 
daunting list of things). This was very challenging for a reviewer, who 
is not. But I did read the whole document. I am incompetent to raise 
issues about the essence of this document. Rather, I have focused on 
more superficial aspects.

ISSUES: 4
NITS: 4

1) ISSUE

Section 2.6.2 says:

"If an implementation's integers support wrapping addition, the 
implementation MUST treat the Sender Sequence Number space as exhausted 
when a wrap-around is detected."

I think I understand the issue, but question how it is stated. Just 
because the implementation does wrapping addition on integers shorter 
than 40 bits, that doesn't mean the implementation isn't capable to 
doing proper 40 bit arithmetic. There must be a better way to say this. 
Perhaps:

"An implementation must treat the Sender Sequence Number space as 
exhausted  when the Sender Sequence Number approaches the maximum value 
it can properly increment."

Also, if an implementation has difficulty handling 40 bit integers, 
won't that also be a problem if it *receives* big sequence numbers?

2) ISSUE

Section 6 says:

"An endpoint MUST be able to distinguish between a Security Context to 
process OSCORE messages ... and a Group OSCORE Security Context ... To 
this end, an endpoint can take into account ... Alternatively, 
implementations can ..."

Why offer alternatives? Why not specify a single unambiguous method?
If there is reason, it would be good to discuss the pros and cons.

3) MINOR ISSUE

Section 2.4 says "The authentication credential of the Group Manager 
SHOULD be encoded according to that same format."

There is no discussion of what conditions would justify violating the 
SHOULD. Without this, many implementers treat SHOULD as MAY. My general 
rule is that every SHOULD must specify that alternative.

4) MINOR ISSUE

Section 7.5 specifies External Signature Checkers. But I couldn't find 
any explanation of their purpose.

I leave it to the authors to decide if there ought to be such an 
explanation.

5) NIT

The Abstract uses "CoAP" acronym without expansion. (Its defined in the 
Intro.) I think this isn't allowed in abstracts, which often stand 
alone. Please expand it in the abstract.

6) NIT: Typo

Section 3.3 says:

"A. and then XOR with X bytes from the Common IV's start, where X is the 
length in bytes of the nonce."

I think the above has a typo that can be fixed by s/A/4/

7) NIT

There is a minor grammatical mistake in section 4:

s/was intended for./was intended./

8) NIT

The IdNits tool reports a number of issues. Many are spurious, but there 
are several downrefs that should be evaluated.