[core] Re: Mohamed Boucadair's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

[Marco Tiloca <[e-mail]>]

Hello Mohamed,

Thanks a lot for your review! Please find in line below our detailed replies to your comments.

A GitHub PR where we have addressed your comments is available at [PR].

Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews) and to submit the result as version -28 of the document.

Thanks,
/Marco

[PR] https://github.com/core-wg/oscore-groupcomm/pull/122

________________________________
From: Mohamed Boucadair via Datatracker <[e-mail]>
Sent: Tuesday, October 7, 2025 4:04 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Mohamed Boucadair's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-core-oscore-groupcomm-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Ccb9508054ed14fcef77a08de05aa6879%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638954426619398033%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1FkxhoZAcpXWT2ttIsAnJ6I7bRab3NTIhGUKMzJb8CE%3D&reserved=0<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-groupcomm%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Ccb9508054ed14fcef77a08de05aa6879%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638954426619423444%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uTm9wYR3yd20VE%2FUUbtXjoIbIl2ZdZiyGaLRbpb0o8s%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Marco, Göran, Francesca, John, and Rikard,

Thanks for the effort put into this spec. I appreciate the discussion in
Section 12, in particular.

Please find below some comments:

# Re-keying & Observe

CURRENT:
   *  Long exchange: an exchange of messages associated with a request
      that is a group request and/or an Observe request [RFC7641].

I wonder whether there any impact of key change on installed observed.

==>MT

By design, there is no impact, except for a very specific case that is detailed below.

As to the general case, Section 3.4 "Additional Authenticated Data" explains that the new element 'request_kid_context' in the aad_array achieves precisely the seamless and safe preservation of active long exchanges (including observations), also after a group rekeying has occurred.


As to the particular case, a group member might be evicted from the group precisely to prevent by construction that any long exchanges can remain active unsafely.

This concerns a particular, delicate situation that can arise during the lifetime of a group and throughout instances of group rekeying, if the Group Manager is configured to reassign Gid values as defined in Section 12.2.1.1.1.

In such a case, in the interest of safely preserving long exchanges, the Group Manager has to additionally store the "Birth Gid" of each group member, i.e., the Gid that was provided to that member at its latest group (re-)joining.

When rekeying the group and thereby establishing a new Gid value, the Group Manager must determine whether there are "elder" group members whose associated "Birth Gid" is equal to the new Gid to establish. If that is the case, then the group rekeying has to effectively evict from the group also such group members.

Consequently, as stated at the end of Section 12.2.1.1.1:

* Excluded elder members could eventually re-join the group, thus terminating any of their ongoing long exchanges (including observations).

* It is ensured by construction that there cannot be long exchanges that are active unsafely. That is, it is ensured that no client can have with the same server two ongoing long exchanges, such that the two respective requests were protected using the same Partial IV, Gid, and Sender ID.

<==


# To whom?

CURRENT:
   How the Security Context is established by the group members is out
   of scope for this document, but if there is more than one Security
   Context applicable to a message, then the endpoints MUST be able to
                                                            ^^^^^^^^^^
   tell which Security Context was latest established.
   ^^^^^^

==>MT

We have rephrased as below, to have the intended meaning explicit.

OLD
> ... then the endpoints MUST be able to tell which Security Context was latest established.

NEW (emphasis mine)
> ... then the endpoints MUST be able to **determine** which Security Context was latest established.

<==


# Capability

CURRENT:
   An endpoint of the group may use the group mode (see Section 7), the
   pairwise mode (see Section 8), or both, depending on the modes it
   supports and on the parameters of the Security Context.

Is there a need to know in advance with a remote endpoint supports one or all
these modes? Does that have impact on how contexts are established?

==>MT

The short, practical answer is "no" to both questions.

There is intentionally a separation between, on one hand, what modes are "enabled to be used" in the group according to the decision of the Group Manager, and, on the other hand, what modes an individual group member supports.

The establishment of the Security Context is largely based on the information and parameters obtained from the Group Manager. That's sufficient to indicate whether one mode, or the other mode, or both are "enabled to be used" in the group. Consequently:

* A group member supporting a mode will be effectively able to use that mode, if that mode is enabled to be used in the group.

* A group member (irrespective of what it supports) knows about the mode(s) that are enabled to be used in the group, while it does not know what another group member supports until communicating with that other group member.

If the use of the pairwise mode is not enabled in the group and/or a group member does not support the pairwise mode, then that group member does not install:

* Pairwise Sender Keys for the other endpoints, in its own Sender Context.

* The Pairwise Recipient Key for any other endpoint, in its own Recipient Context corresponding to that other endpoint.

The above is highlighted in Figure 1 of Section 2. Similarly, other parameters in the Common Context are not relevant to install if they pertain to a mode that is not enabled to be used in the group and/or that the endpoint does not support.

<==


# How the limit is know? Can that be retrieved from the system and exposed to
the app?

CURRENT:
   An endpoint may admit a maximum number of Recipient Contexts for a
   same Security Context, e.g., due to memory limitations.  After
   reaching that limit, the endpoint has to delete a current Recipient
   Context to install a new one (see Section 2.6.1.2).  It is up to the
   application to define policies for Recipient Contexts to delete.

==>MT

It's not that the maximum number can be "retrieved from the system and exposed to the app".

Like stated later in Section 2.6.1.2, "Group OSCORE in itself does not establish a maximum number of Recipient Contexts".

In fact, the application is also meant to define that maximum number, together with the policies about deleting Recipient Contexts.

We have rephrased and improved the last sentence as below:

OLD
> It is up to the application to define policies for Recipient Contexts to delete.

NEW (emphasis mine)
It is up to the application to define **the maximum number of Recipient Contexts for a same Security Context as well as policies for deleting** Recipient Contexts.

<==


# Tracking/Logging

CURRENT:
   The Security Context may contain a large and variable number of
   Recipient Contexts.  While Group OSCORE in itself does not establish
   a maximum number of Recipient Contexts, there are circumstances by
   which implementations might choose to discard Recipient Contexts or
   have to do so in accordance with enforced application policies.  Such
   circumstances include the need to reclaim memory or other resources
   on the node hosting the endpoint, for example because the predefined
   maximum number of Recipient Contexts has been reached in the Security
   Context (see Section 2.2).

How these discarded contexts are tracked? Are there some king of
alarm/notification to warn this?

==>MT

They are not tracked and Group OSCORE in itself does not need to specifically track/log their deletion.

Group OSCORE in itself only needs to switch into initializing the Replay Window of new Recipient Contexts as invalid, if those are created after the first deliberate deletion of a Recipient Context (see third paragraph in Section 2.6.1.2).

If an endpoint N_1 deletes a Recipient Context associated with another endpoint N_2, then N1 will be later able to create a new Recipient Context associated with N_2, when receiving a message from N_2 (just like it did the first time).

Since the application might have some interest in logging these deletions, we have extended the text as follows.

NEW (emphasis mine)
> Such circumstances include ..., for example because the predefined maximum number of Recipient Contexts has been reached in the Security Context (see Section 2.2). **Implementations can provide means for the application to gain knowledge about the deliberate deletion of Recipient Contexts, e.g., through notifications sent to the application and/or logs made available to the application.**

<==


# Is there a reason what the Group Manager may not be informed? Shouldn’t such
event be logged locally, btw? Shouldn’t the manager be contacted prior to
exhaustion and not wait for full exhaustion?

CURRENT:
   Upon exhausting the Sender Sequence Number space, the endpoint MUST
   NOT use this Security Context to protect further messages including a
   Partial IV.

   When approaching the exhaustion of the Sender Sequence Number space,
   the endpoint SHOULD inform the Group Manager, retrieve new Security
   Context parameters from the Group Manager (see Section 2.6.3), and
   use them to derive a new Sender Context (see Section 2.2).

==>MT

Addressing the three questions in order:

**1.** Is there a reason what the Group Manager may not be informed?

There is no particular reason to inform the Group Manager specifically about that.

In principle, the endpoint in question can also live with the situation safe and well, as long as it is not going to consume new values of its Sender Sequence Number. This is the case, e.g., if the endpoint plans to not send any message at all for a long while, or only to send first-responses to a given request (which do not need to consume a Sender Sequence Number).

In order to start over with new keying material and Sender Sequence Number 0, indeed an interaction with the Group Manager is required. That interaction is specifically a request to re-join the group or for only obtaining a new Sender ID, and it abstracts away from the particular underlying reason.

**2.** Shouldn't such event be logged locally, btw?

We don't see any particular reason or advantage in doing that.

**3.** Shouldn't the manager be contacted prior to exhaustion and not wait for full exhaustion?

Indeed. This is what the fourth paragraph in the same Section 2.6.2 already says after the quoted text above, i.e.:

> It is RECOMMENDED that the endpoint takes this course of action with some margin, i.e., well before exhausting the Sender Sequence Number space, in order to avoid a period of inability to protect messages including a Partial IV.

<==


# Not new behavior: cite as quote

OLD:
   As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent
   over multicast MUST be Non-confirmable, and thus are not
   retransmitted by the CoAP messaging layer.

NEW:
   As per [RFC7252][I-D.ietf-core-groupcomm-bis], “group requests sent
   over multicast MUST be Non-confirmable”, and thus are not
   retransmitted by the CoAP messaging layer.

And

OLD:
   According to Section 5.2.3 of [RFC7252], responses to Non-confirmable
   group requests SHOULD also be Non-confirmable,

NEW:
   According to Section 5.2.3 of [RFC7252], “responses to Non-confirmable
   group requests SHOULD also be Non-confirmable”,

==>MT

Let's take the two suggestions separately.


**On the first suggestion**, there is no single, common sentence that we can quote verbatim from those two documents. The closest sentences that they have are:

In RFC 7252

* Section 8.1, "Such multicast requests MUST be Non-confirmable."

In draft-ietf-core-groupcomm-bis

* Section 3.1.1, "All CoAP requests that are sent via IP multicast MUST be Non-confirmable (NON)".

* Section 3.6, "An IP multicast request MUST be Non-confirmable (Section 8.1 of [RFC7252])."

Instead, we have rephrased as below to simply state a fact, without restating through normative language, i.e.:

NEW (emphasis mine)
> As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent over multicast **are always** Non-confirmable, and thus are not retransmitted by the CoAP messaging layer.


**On the second suggestion**, that works but we have to use (part of) the sentence from RFC 7252 verbatim, i.e.:

> If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) in reply to a Confirmable request, or a Confirmable response in reply to a Non-confirmable request.

So we have extended our text as below.

OLD
> According to Section 5.2.3 of [RFC7252], responses to Non-confirmable group requests SHOULD also be Non-confirmable, but endpoints MUST be prepared to receive Confirmable responses in reply to a Non-confirmable group request.

NEW (emphasis mine)
> According to Section 5.2.3 of [RFC7252], **"[i]f the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive (...) a Confirmable response in reply to a Non-confirmable request."**

<==


Cheers,
Med