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

[Marco Tiloca <[e-mail]>]

Hello Deb,

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/124

________________________________
From: Deb Cooley via Datatracker <[e-mail]>
Sent: Monday, October 6, 2025 7:46 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: Deb Cooley's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

Deb Cooley 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%7Cb97e891e8e974cbf953308de05003bc8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638953695736730514%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pFxz8ALu3n%2F76bs%2FGu1vogYPZ3gNDkgRy10S1O2eprk%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%7Cb97e891e8e974cbf953308de05003bc8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638953695736752306%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EWH3EL07J3ULFlPZ1vxNkiYdM9hPcYwsdiBhJuYAgSY%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/>



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


While I'm balloting No Obj on this draft, I'd like a response to the comments
I've listed below.

This draft is appears to be quite complicated (and require knowledge of no less
than 9-10 specifications).  A quick review shows that there are plenty of
places where signat encryption, and key agreement are confused. Crisper use of
terminology here would be best. I've given an example below, and I'd be happy
to help work on this.

Thanks to Mališa Vučinić for their secdir review.

==>MT

Thanks for pointing out the inexplicable confusion of encryption and ECDH.

Later in this response, we have listed a few other instances in the same example. Please let us know if there is still confusion.

<==


Section 1.1:  Use of the phrase 'Master Secret' is being replaced (TLS has
already removed it).  Will it be replaced here, maybe with a note to the pre
existing specifications? [Note:  this applies to 'Master xxxx']

==>MT

The term 'Master Secret' as used in this context was coined in RFC 8613, and in another age.

As you noted, there are already a number of related publications in this area and this term is used in several ones, including RFC 9031, RFC 9203, RFC 9528, RFC 9668, 3GPP AKMA (TS 33.535), and OMA Specworks L2wM2M (core specification).

Changing the terminology in this document will most likely not cause any change in the use of this established term and only create confusion. The change of this particular term has been discussed before, for example in the review of what became RFC 9528, and the agreement at the time was to not make any change.

With this in mind, we propose to stay with the terminology currently used.

<==


Section 2, Authentication Credential Format:  This section references Section
2.1.5, which then references Section 2.4 without much clarifying information.
Recommend skipping the double ref and just reference Section 2.4 here.

==>MT

With reference to the inner bullet point in Section 2.0:

> The new parameter Authentication Credential Format, specifying the format of authentication credentials used in the group (see Section 2.1.5).

The final part of the sentence can indeed better refer to Section 2.4.

The first part of the sentence can still refer to Section 2.1.5, where the parameter Authentication Credential Format is introduced. The intent of Section 2.1 is to have a section 2.1.x for each parameter of the Common Context.

With that in mind, we have made the following rephrasing:

OLD
> The new parameter Authentication Credential Format, specifying the format of authentication credentials used in the group (see Section 2.1.5).

NEW
> The new parameter Authentication Credential Format (see Section 2.1.5), specifying the format of authentication credentials used in the group (see Section 2.4).

<==


Section 2, Signature Encryption Key:  Not entirely sure what this means.  Is
this a symmetric key? (it is apparently an AEAD or something like that.

==>MT

In Section 2.0, "Signature Encryption Key" is just referring to a parameter.

Its content is defined in the referred Section 2.1.9, which says that the parameter specifies the encryption key named Signature Encryption Key.

The Signature Encryption Key is an encryption key that is derived by means of the same HKDF-based construct used to derive AEAD encryption keys (see Section 3.2.1 of RFC 8613).

However, the Signature Encryption Key is not used to perform an AEAD encryption. Rather, it is used for deriving a keystream to encrypt/decrypt a countersignature (see Sections 4.1, 4.2, 7.2, and 7.4)..

To clarify, we have made the following consistent rephrasing in Section 2.0:

OLD
> Group Encryption Algorithm, used for ...

NEW
> Group Encryption Algorithm, specifying the algorithm used for ...

OLD
> Signature Algorithm, used for ...

NEW
> Signature Algorithm, specifying the algorithm used for ...

OLD
> Signature Encryption Key, used for ...

NEW
> Signature Encryption Key, specifying the encryption key used for deriving a keystream, which is in turn used for ...

<==


Section 2, pairwise mode:  static-static DH to derived a shared secret, etc.
isn't common...  for a reason.  Please explain why it is ok in this
specification.

==>MT

Given two endpoints, their static key pairs are used only to derive a Diffie-Hellman shared secret (see Section 2.5.1).

In turn, the shared secret is only one input to the derivation of the pairwise keys that are effectively used to protect messages with the pairwise mode of Group OSCORE.

Other inputs are the Sender Key and Recipient Key of the two endpoints, which are in turn derived from the group keying material of the latest established Security Context and from the latest enpoint identifiers.

Effectively, the Sender Key and Recipient Key are used to "salt" the derivation of the Pairwise Sender/Recipient keys.

In fact, as explained in the second from last paragraph of Section 2.5.1, the pairwise keys are discarded after "establishing a partially or completely new Security Context (see Section 2.6 and Section 12.2)". Consequently, newly computed ones will build on the same Diffie-Hellman shared secret (due to the static Diffie-Hellman keys), but on different Sender/Recipient keys used as salt.

A related point was raised in another review during IESG evaluation, for which we are also updating the document as below.

* In Section 2.1.10, we have added a new paragraph after the currently first one:

> When two endpoints compute their Diffie-Hellman shared secret, the Pairwise Key Agreement Algorithm takes as input the static-static Diffie-Hellman keys of the two endpoints. The lifetime of those keys is the same as the lifetime of the authentication credentials that the two endpoints use in the group. As detailed in Section 2.5.1, the derivation of the pairwise keys takes as input not only the Diffie-Hellman shared secret, but also group keying material from the latest established Security Context.

* In Section 2.5.1, we have swapped and updated the last two paragraphs as below:

OLD
> After establishing a partially or completely new Security Context (see Section 2.6 and Section 12.2), the old pairwise keys MUST be deleted. Since new Sender/Recipient Keys are derived from the new group keying material (see Section 2.2), every group member MUST use the new Sender/Recipient Keys when deriving new pairwise keys.
>
> As long as any two group members preserve the same asymmetric keys, their Diffie-Hellman shared secret does not change across updates of the group keying material.

NEW
> As long as any two group members preserve the same asymmetric keys, their Diffie-Hellman shared secret does not change across updates of the group keying material. **The lifetime of those keys is the same as the lifetime of the authentication credentials Sender Auth Cred and Recipient Auth Cred.**
>
> After establishing a partially or completely new Security Context (see Section 2.6 and Section 12.2), the old pairwise keys MUST be deleted. Since new Sender/Recipient Keys are derived from the new group keying material (see Section 2.2), every group member MUST use the new Sender/Recipient Keys when deriving new pairwise keys.

<==


Section 2.1.7, para 2:  It is odd that AES CBC mode is being suggested, give
the issues with the CBC mode.  What makes CBC mode more appropriate than CTR
mode?

==>MT

Thanks for this comment.

After more discussion and considerations, we believe that it is actually better to avoid AES-CBC (also due its padding and related vulnerabilities) and instead consider AES-CTR as a possible non-authenticated Group Encryption Algorithm to use.

To this end, we have also defined in detail how to compose the 128-bit counter block for encryption, building on the Group OSCORE nonce computed as defined in Section 3.3 of the present document.

In particular, we have updated the draft as follows:

**2.1.4 "Common IV"**

We have added the following text at the end of the section:

NEW
> If the Group Encryption Algorithm is A128CTR, A192CTR, or A256CTR (see Section 4 of [RFC9459]), then the length of the nonce used by that algorithm is 12 bytes (see Section 2.1.7).

**2.1.7 "Group Encryption Algorithm"**

We have replaced the last paragraph as below.

OLD
> A non-authenticated algorithm MUST NOT be used as Group Encryption Algorithm if it is not possible to ensure uniqueness of the (key, nonce) pairs. This is the case, for instance, for A128CTR, A192CTR, and A256CTR [RFC9459]. Instead, examples of non-authenticated algorithms that can be used as Group Encryption Algorithm are A128CBC, A192CBC, and A256CBC [RFC9459].

NEW
> In order to be eligible to use as Group Encryption Algorithm, a non-authenticated algorithm MUST ensure that the same key is not reused with the same IV or intermediate values used in the algorithm, e.g., for algorithms that increment the IV internally. If a non-authenticated algorithm does not fulfill the requirement above, that algorithm MUST NOT be used as Group Encryption Algorithm.
>
> Examples of non-authenticated algorithms that can be used as Group Encryption Algorithm are A128CTR, A192CTR, and A256CTR (see Section 4 of [RFC9459]). When either of those three algorithms is used, the following applies:
>
> * A 12-byte nonce MUST be computed as defined in Section 3.3 of this document.
>
> * The Initialization Vector (IV) used in Section 4 of [RFC9459] is equivalent to the nonce above (12 bytes) concatenated with 0x00000000 (4 bytes), in this order.
>
> * The algorithm MUST NOT be used to encrypt a plaintext or decrypt a ciphertext whose length is larger than 64 GB (i.e., 2^36 bytes).
>
> The non-authenticated algorithms A128CBC, A192CBC, and A256CBC (see Section 5 of [RFC9459]) MUST NOT be used as Group Encryption Algorithm.
>
> Future specifications can admit alternative non-authenticated algorithms that can be used as Group Encryption Algorithm. When doing so, it MUST be defined how to securely compose the IV and possible intermediate values used in the algorithm, building on the nonce computed as defined in Section 3.3 of this document. Absent such a specification, alternative non-authenticated algorithms MUST NOT be used as Group Encryption Algorithm.

**Section 10 Implementation Compliance**

We have update the text as below:

OLD
> For endpoints that use non-authenticated encryption, the algorithm A128CBC defined in Section 5 of [RFC9459] is mandatory to implement as Group Encryption Algorithm (see Section 2.1.7).

NEW
> For endpoints that use non-authenticated encryption, the algorithm A128CTR defined in Section 4 of [RFC9459] is mandatory to implement as Group Encryption Algorithm (see Section 2.1.7).

OLD
> Section 6 of [RFC9459] mandates that COSE libraries supporting either the AES-CTR or AES-CBC algorithm and accepting Additional Authenticated Data (AAD) as input must return an error if one of these non-AEAD content encryption algorithms is selected.

NEW
> Section 6 of [RFC9459] mandates that COSE libraries supporting the AES-CTR algorithm and accepting Additional Authenticated Data (AAD) as input must return an error if AAD is provided when such a non-AEAD content encryption algorithm is selected.

**13.1 Implementation \#1**

We have update the text as below:

OLD
> ... ChaCha20/Poly1305, A128CBC, A192CBC, A256CBC.

NEW
> ... ChaCha20/Poly1305, A128CTR, A192CTR, A256CTR.

**13.2 Implementation \#2**

We have update the text as below:

OLD
> The following COSE encryption algorithms: 1-3, 10-13, 24, 30-33, -65531

NEW
> The following COSE encryption algorithms: 1-3, 10-13, 24, 30-33.

**13.3 Interoperability**

We have update the text as below:

OLD
> - (ChaCha20/Poly1305, AES-CCM-16-64-128).
>
> - (A128CBC, AES-CCM-16-64-128).

NEW
> - (ChaCha20/Poly1305, AES-CCM-16-64-128).

<==


Section 2.5:  EdDSA and ECDSA are mentioned in the section, I assume one would
use ECDH for key agreement (vice encryption).  While this section doesn't need
every detail to be perfect, it needs to be closer than this.  Perhaps something
like:  'Elliptic Curve Cryptographic public/private key pairs can be used for
both signature and key agreement'.

==>MT

We have identified and fixed the following confusing text.

**Section 2.5 (first paragraph)**

OLD
> Certain signature schemes, such as EdDSA and ECDSA, support a secure combined signature and encryption scheme.

NEW
> In certain Elliptic Curve Cryptographic schemes, it is possible to use public/private key pairs with both signature operations (ECDSA or EdDSA) and key agreement operations (ECDH).

**Section 2.5 (second paragraph)**

OLD
> Group OSCORE keys used for both signature and encryption MUST be used only for purposes related to Group OSCORE.

NEW
> Group OSCORE keys used for both signature operations and key agreement operations MUST be used only for purposes related to Group OSCORE.

**Section 8**

OLD
> ... , the signature scheme of the group mode MUST support a combined signature and encryption scheme.

NEW
> ... , the public/private key pairs used for signature operations of the group mode MUST be possible to also use for key agreement operations.

<==


Section 5.1, para 3:  'remain active indefinitely',  seems like a bad idea,
especially if the group is rekeyed.  Maybe put a cap on how long?  Especially
from a cryptography point of view.

==>MT

We agree that "indefinitely" might give a wrong impression and is not accurate.

As a start, we have removed "indefinitely" from the quoted sentence in Section 5.1, i.e.:

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

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


Per Section 3.4, a long exchange can remain active precisely throughout instances of group rekeying, thanks to the 'request_kid_context' element within the aad_array used for processing a message. That element "enables endpoints to safely keep a long exchange active beyond a possible change of Gid (i.e., of ID Context), following a group rekeying".

In fact, there is a cap for the duration of a long exchange. This is summarized by the last paragraph of Section 5.1:

> 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.

In addition to that, 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.

* 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.

<==


Section 14.11:  Is secure distribution of these keys discussed in any of the
many of specifications referenced?  It does not appear to be addressed in this
draft.  (nor is it listed as out of scope).

==>MT

We believe that this comment builds on the sentence:

> This includes the case where the Group Manager rekeys the group by generating and distributing a new Master Secret.

Both points raised in the comment are covered in Section 12.2, which says:

> The specific group key management scheme used to distribute new keying material is out of the scope of this document. A simple group key management scheme is defined in [I-D.ietf-ace-key-groupcomm-oscore].

The referred document specifies a possible realization of Group Manager, which provides all the functionality expected for a Group Manager and compiled in Appendix D of the present document.

<==