[core] Re: AD Review: draft-ietf-core-oscore-groupcomm

[Marco Tiloca <[e-mail]>]

Hello Mike,

Thanks for the detailed AD review.

We are processing your comments towards producing a PR and ultimately the next version -26 of the document. We will come back to you soon.

Best,
/Marco


Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se
________________________________
From: Mike Bishop <[e-mail]>
Sent: Wednesday, June 18, 2025 6:01 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: AD Review: draft-ietf-core-oscore-groupcomm

Since dns-over-coap was turned around so quickly, I'm following up on this one to ensure I didn't miss a reply. (Also copying the WG list, since I omitted to do that previously.)

________________________________
From: Mike Bishop <[e-mail]>
Sent: Wednesday, May 28, 2025 11:43 AM
To: [e-mail] <[e-mail]>
Subject: AD Review: draft-ietf-core-oscore-groupcomm

Apologies for how long I took with this — I'm still trying to find my balance between IESG reviews and AD reviews for documents coming out of WGs. I have a lot of comments and even more minor nits, but I don't think anything here major. This is a nice, solid document and I appreciate the work you and the working group have clearly put into it.

First, I really appreciated both the thorough Terminology section and the example use cases in Appendix B. Thanks for helping to establish a baseline for reading the rest of the document.

The shepherd write-up stops mid-sentence when explaining why RFC5869 is fine to not be normative, but I note that it was made normative in the latest rev of the document instead.

In 1.1, a link to the lifecycle of the group identifiers would be useful; the definition of "Birth Gid" suggests that the Gid can change over time, but details aren't conveniently accessed from here.

In Section 2.1.6, consider a link to the specifics of "achieve proof-of-possession of the corresponding private key".

In Section 2.4, consider whether the references here are actually only informative. Given that 1.1 uses these as "examples" of credentials, it's probably fine, but perhaps make it clear here that these are expanding on the "e.g." in the first paragraph. Maybe expand that into a "For example:" followed by bullets, the first of which is the current e.g.?

In Section 2.5.1, the construction is described as "the same" as RFC8613, but it looks like the key replaces the Master Salt? Consider stating the differences explicitly. Also, does this section need an informative reference to RFC 8152 for definition of EC2 keys?

In Section 2.5.3, "On the other hand" sounds like discussing trade-offs between valid options, but this is required behavior. Perhaps shift to a statement that this will result in exhausting the space more quickly than standard OSCore?

In Sections 2.6.1.x, several thoughts:

  *
Consider aligning the titles to split between "total loss" and "partial loss" of the Context.
  *
With regard to partial loss, there appears to be no protocol reason why a Recipient Context ever needs to be deleted, and the protocol does not establish a maximum number of RCs. Consider rephrasing this to say that implementations might choose to discard Recipient Contexts in various circumstances, including to reclaim memory or other resources. (But keep the reference to 2.2 to describe that case.)
  *
The directions in 2.6.1.2 presuppose that an endpoint can differentiate a sender where the corresponding Recipient Context was deleted from one where no Recipient Context has yet been derived. That implies the requirement to perpetually remember the list of senders whose contexts have been deleted, i.e. this is a portion of the Security Context that will always grow in size and never decrease. This by itself might force a constrained node to discard the entire Security Context and generate a fresh one. Consider explicitly mentioning the requirement to keep this information and calling out this case.
  *
If messages cannot be passed to an application from a re-derived Recipient Context, it seems effectively useless, right? The RECOMMENDED path remedies this state, but it's not mandatory. The other option (MAY) discards the re-derived Recipient Context anyway, as a full new Security Context is generated. That means keeping the useless context is still a spec-compliant path. Consider reframing this to say that an endpoint MUST take one of three paths:
     *
Discard incoming messages from this recipient
     *
Re-establish a valid Replay Window as per 9
     *
Refresh the Security Context as per 2.6.3
  *
Consider whether 2.6.2 should be grouped under 2.6.1 -- there are three situations in which an endpoint might need to refresh its context: total loss, partial loss, or space exhaustion. Then you can discuss how to establish a fresh Security Context in any of those cases.
  *
Should endpoints attempt to get a fresh Security Context somewhat in advance of exhaustion, to avoid a period of inability to send?

Should Section 4.2 be an appendix? If not, "as defined in Section 4" reads oddly in the current location, since this is Section 4, though I think you're actually referring to the top-of-section text.

In Section 5.2, it feels strange to say "guarantees" and then rely on honesty of the peer; that sounds less like a guarantee and more like a goal.

In Section 5.3.1, clients MUST detect reused Partial IVs but only MAY have an only-newer policy which avoids remembering more than one PIV value for the peer. It may be worth mentioning the additional storage that's needed if an implementation chooses to allow older responses while still correctly detecting the Partial IV reuse, and the need to bound that storage. An only-newer policy would be the extreme special case of a bound on the storage.

In several locations (Sections 7, 7.2, 14.9), we have a SHOULD followed by a link to a document that doesn't comply with the SHOULD. There should be explanations of what types of situations might warrant not following the guidance given, with the document as an example of such a situation.

In Section 7, the two cases for not sending error messages seem to cover 100% of the time; should the first one be "not able to identify whether the received request is a group request"?

In Section 7.1, the explanation that the invariant identifier makes it "simpler" and guards against "missed ... messages" sounds like the explanation of a SHOULD. Is this actually required for compatibility or merely recommended? If required, consider rewording the explanation.

In Section 7.2, step 6, it's odd to have a MUST followed by what to do if you can't. Wouldn't this either be a SHOULD followed by "if not, you MUST..." or MUST on the outcome and ordering the operations is the recommended way to achieve that? Similar comment on Section 7.4 step 6.

Several elements of 7.x are later reused by reference in 7.x and 8.x. Should those things be in a more general section which all three then reference? E.g. elements of 7.2 in 7.4 and 8.4; elements of 7.1 in 7.3 and 8.3, 7.3 in 8.5, etc.

The last paragraph of Section 8 is an interesting case -- deliver the message to many recipients where that's easier and use encryption to ensure only the target actually reads it. This somewhat contradicts the statement in 8.1 that "the sender needs to know the individual address of the recipient endpoint." Clearly it doesn't, though it's helpful; it just needs some way to have the message delivered to the recipient, which might be broadcast or multicast.

In Section 8, Silent servers don't support pairwise, but pairwise MUST be supported to mitigate an attack (in Section 14.9) in the next paragraph. One section or the other should explicitly state why silent servers aren't exposed to this attack and therefore don't need mitigation. In Section 14.14, silent servers are told to "adopt alternative approaches," but nowhere do we say what those might be.

In Section 9, "the subsequent client request" assumes a request that hasn't been required yet. Is this "the next client request" assuming the client will eventually make one? Or is it directing the client to make one upon receipt of this message, i.e. "the client MUST/SHOULD send a request echoing...."?

Also in Section 9, it's unclear to me whether "all the other values" is actually intended to be all earlier values, all later values, or both. Read literally, it's both, but "lower limit" implies it's an edge.

In Section 10, "Existing devices can be expected to support either EdDSA or ECDSA. In order to enable as much interoperability as we can reasonably achieve..." will age poorly. I'd skip these two sentences and go straight to SHOULD implement at least one of the preferred algorithms. (SHOULD support both seems unnecessary, since it's already compliant with supporting at least one.) This applies to both the group and pairwise discussions.

In Section 12.2.1.1, the reference to Appendix E seems to be normative; generally the appendices are not normative. I would consider importing this into Section 12 or creating a new section if needed.

In Section 12.2.1.2, "reassign" could potentially be read as giving the same Sender ID to a new owner or giving a given endpoint a different Sender ID. Perhaps make this sentence more explicit that "MUST NOT assign a given Sender ID to multiple endpoints."

In Section 14, every subsection of Appendix D in RFC8613 is incorporated by reference. Consider just incorporating Appendix D once, potentially mentioning the various topics discussed there.

There are several places where counterfactual potential attacks are described. Since these are attacks the protocol already mitigates, I'm not certain that detailed attack descriptions are more valuable than they are confusing. Consider simplifying these. For example:

  *
In Section 14.1, the example given in the last two paragraphs of the third bullet might be confusing. First, the endpoints *do* delete the Recipient Context. Second, it's buried within an extended bullet point. Consider extracting it and reframing it as 'because the endpoints delete the Recipient Context, an attack of this nature can be detected.'
  *
The end of Section 14.7.2, beginning from "If, hypothetically," seems unnecessary. The section already covers that the security is provided by covering the OSCORE option; does describing the attack that won't work improve that?
  *
Section 14.8 also describes an attack that doesn't work against the protocol as specified.

In Section 14.2, if the shared secret of two group members is leaked, that would also permit the attacker to decrypt traffic between those two members, including stored past traffic, I think? That risk is not mentioned here.

Section 14.9 contains an Editor's Note to align with the content of ietf-core-groupcomm-bis; I think the time has come to do that and remove the note.

--- NITS FOLLOW ---

2. "silent server" => "a silent server"? Also in 2.6.1.1 and possibly others.

2.5 remove comma after "pairwise keys"

2.6 - For content that "may need to be updated," "immutable" may not be the best term to use. Perhaps "long-term" or "stable"?

2.6.1 - "due to a reboot occurred in an unprepared way" => "if a reboot occurred in an unprepared way" or "due to an unexpected reboot", also in 2.6.1.1

Consider aligning the titles of 2.6.1.x to split between

2.6.1.1 - "as currently unable" => "as it is currently unable"

2.6.1.1 - Should this adversary discussion move to the Security Considerations?

2.6.1.2 - "does not only result" => "not only results"

Consider rewording "receives a request to process" to be clearer that the endpoint is processing the request, not being requested to perform processing. The current phrasing is correct, but potentially difficult to parse.

3. - Extra comma after "apply"

3.4 - "external_aad field"? "external_aad structure"?

Remove comma after "[RFC8613]"

Not immediately clear that AEAD Algorithm, Group Encryption Algorithm, etc. are Common Context fields. "Specify" may not be the correct verb here. Maybe "MUST be set to the value of the AEAD Algorithm parameter from the Common Context"? (And similar throughout.)

4.1 - "SHALL be derived as follows" => "is derived"? Consider moving the RFC8610 note to the Terminology section. "in case of" => "in the case of"

5.1 - "exchange" => "exchanges" or "each of its" => "each";

CURRENT: Group OSCORE allows to preserve a long exchange active indefinitely, even in case the group is rekeyed, with consequent change of ID Context, or in case the client obtains a new Sender ID.

MAYBE: Group OSCORE allows a long exchange to remain active indefinitely, even if the group is rekeyed (changing the ID Context) or the client obtains a new Sender ID.

CURRENT: Upon leaving the group or before re-joining the group, a group member MUST terminate all the ongoing long exchanges that it has started in the group as a client, and hence frees up the CoAP Token associated with the corresponding request.

MAYBE: Upon leaving the group or before re-joining the group, a group member MUST terminate all the ongoing long exchanges that it has started in the group as a client. This frees up the CoAP Token associated with the corresponding request.

5.2 - Remove comma after 9175 reference.

5.3 - Is 2.6.1 the right reference for updating Replay Windows? That discusses recovering from loss of state, and points on to Section 9 for recovery of the Replace Window.

Remove comma after "one" in the last paragraph

6. - Consider "parameters" instead of "algorithms"; remove commas around "if the Group Flag is set to 0"

7. - Is "candidate" the correct term when a member is receiving the security information from the group? I would think "new", since they now have the appropriate credentials.

Remove comma after "proxy"

Remove comma after "request"; "any of the two" => "either of the"

7.x - SHALL in opening statements feels unnecessary, this is simply how it's done. No need for a comma before "with the following modifications"

7.1

"even in case" => "even if"

"such an invariant" => "this"

7.2 - Remove comma after "countersignature"

"a retry time...." => "Section 5.10.5 of [RFC7252] specifies a default retry time of 60 seconds."

"even in case" => "even if"

CURRENT: "Such a configuration, which is specified by the application, mitigates..."

CONSIDER: "When this behavior is specified by the application, it mitigates..."

7.3 - Remove comma after "responses"

"any of the following two" => "either of the following"

"compared to what" => "than" (x2)

Remove comma after "synchronize"

CURRENT: For each ongoing long exchange, the server can help the client to synchronize, by including also the 'kid context' parameter in responses following a group rekeying, with value set to the ID Context (Gid) of the new Security Context.

CONSIDER: In responses which are part of a long exchange, the server can help the client to synchronize following a group rekeying by setting the 'kid context' parameter to the ID Context (Gid) of the new Security Context.

Remove comma after "Manager" and "synchronize"

Remove comma after "mode"

7.4 - Remove commas after "present", "countersignature", "below", "[RFC9338]"

"even in case" => "even if"

"to which the request was intended for" => "for which the request was intended" or "to which the request was sent"

7.5 -

CURRENT: "The support for signature checkers from the Group Manager is defined in Section 12.3."

CONSIDER: "The data signature checkers need from the Group Manager is described in Section 12.3."

8. and 8.x - Remove commas after "[RFC8613]"

8. - "any other member" => "one other member"?

CURRENT: "The pairwise mode cannot be used to protect messages intended for multiple recipients. In fact, the keying material used for the pairwise mode is shared only between two endpoints."

CONSIDER: "The pairwise mode cannot be used to protect messages intended for multiple recipients, as the keying material used for the pairwise mode is shared only between two endpoints.

9 - Remove commas after "client", "below", "more recent one", "Replay Window"

"In case" => "If"

"fresh, as conveying" => "fresh via"

10 - "mandatory-to-implement HKDF"

12 -

CURRENT: This document is based on the existence of an entity called Group Manager that is responsible for the group, but it does not mandate how the Group Manager interacts with the group members.

CONSIDER: A Group Manager is responsible for distributing security information within the group. The protocol used between the group members and the Group Manager is outside the scope of this document.

12.2 - "in case one" => "when one"

"are member" => "are members"

"MUST rekey the group also" => "MUST also rekey the group"

CURRENT: "The group member asks the Group Manager for the set of stale Sender IDs."
CONSIDER: "The group member asks the Group Manager for the set of stale Sender IDs between GEN_OLD and GEN_NEW."

"Such a strictness" => "Strictness"

14. - "results in a practically limited risk" => "limits this risk in practice"

"thus safely enabling to keep long exchanges active" => "making it possible to keep long exchanges active safely"

Remove comma after "ID Context (Gid)"

"is computed also" => "is also computed"

Make "Sections 11.2-11.6 of [RFC7252]" a (pair of?) proper link if possible

14.1 - "commonly shared" => "shared"

CURRENT: "The following refers to group members as the endpoints in the group storing the latest version of the group keying material."

CONSIDER: "In this section, the term 'endpoints' refers to group members which possess the latest version of the group keying material."

CURRENT: "Also, the countersignature is encrypted by using a keystream derived from the group keying material (see Section 4). This ensures group privacy, i.e., an attacker cannot track an endpoint over two groups by linking messages between the two groups, unless being also a member of those groups."

CONSIDER: "The countersignature is also encrypted using a keystream derived from the group keying material (see Section 4). This ensures group privacy, i.e., an attacker cannot track an endpoint over two groups by linking messages between the two groups unless the attacker is also a member of both groups."

"in case of members' leaving, and" => "when members leave and"

14.2 - "any of those two group members" => "either group member to the other";

"contemplated, as more likely to happen" => "considered more likely"

14.3 - "same considerations" => "the same considerations" or "the considerations" (twice)

14.5 - "a same message" => "the same message" or "a given message"

14.5.1 -

CURRENT: However, the server would better and more simply discard such an incoming request.
CONSIDER: However, the server could simply discard such an incoming request which [has better security properties?].

"admit" => "permit"

14.7 - "A same" => "The same" or "A given"

CURRENT: This practically relies on altering the content of the OSCORE Option, and having the same MAC in the ciphertext still correctly validating, which has a success probability depending on the size of the MAC.

CONSIDER: This relies on altering the content of the OSCORE Option without invalidating the MAC in the ciphertext, which has a success probability depending on the size of the MAC.

14.7.1 - "More in detail" => "In more detail" or "Specifically"

14.7.2 - "takes as input also" => "also takes as input"

14.12 -

"also Group OSCORE relies" => "Group OSCORE relies"
"preserved also when" => "preserved when"
"resuming to accept" => "accepting further"

14.13 - "In case" => "If"

14.14 - "be victim" => "be the victim"; ", in case" => "if"; "very server" => "server"; "mix up" => "transpose" or "swap"?

C - "specifically formatted" => "formatted"

E - Delete "In fact,"