[core] Re: Paul Wouters' No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

[Marco Tiloca <[e-mail]>]

Hello Paul,

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


________________________________
From: Paul Wouters via Datatracker <[e-mail]>
Sent: Thursday, October 23, 2025 3:12 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Paul Wouters' No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

Paul Wouters 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%7Cc570f71f45bf42b4f38708de1235d85d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638968219629495316%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cg6l950vXvkPVu6iAf6squ9S%2Fl7%2F%2BImMbfQvQSX6R%2F0%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%7Cc570f71f45bf42b4f38708de1235d85d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638968219629543274%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8TpZjRou54BqIUCbEOzgqb%2BTXbsVQ2BVutCGkji51v8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/>



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

Note I am concerned about long term use of static-static DiffieHellman keys,
and would appreciate an answer to my question below.

        The AEAD Algorithm (see Section 3.1 of [RFC8613]) SHALL identify

I think this should just say "identifies" without a SHALL ?

        The HKDF Algorithm (see Section 3.1 of [RFC8613]) SHALL identify the

same

        The ID Context parameter (see Sections 3.1 and 3.3 of [RFC8613]) SHALL
        contain

same

        The Common IV parameter (see Section 3.1 of [RFC8613]) SHALL identify
        the

same

==>MT

We have applied the suggested changes.

<==


Section 2.1.7

Probably state that an AEAD is prefered over non-AEAD ?

==>MT

The Group Encryption Algorithm covered by this section pertains to the group mode. When using the group mode, a countersignature is present and ensures integrity protection.

So, from a security point-of-view, there is no particular benefit to prefer an AEAD algorithm over a non-AEAD algorithm. On the other hand, one may prefer a non-AEAD algorithm due to the smaller overhead that it results in.

We have made the following rephrasing:

OLD
> This algorithm MAY provide integrity protection.

NEW
> This algorithm MAY provide integrity protection. If it does not, integrity protection is still provided by the countersignature added to the message due to the use of the group mode.

<==


Section 2.1.9

        deriving a keystream to encrypt/decrypt

Maybe call this a symmetric key instead of keystream ? Same for the use of
KEYSTREAM?

==>MT

We have added a forward reference to Section 4.2 that defines how the keystream is derived, i.e.:

OLD
> ... for deriving a keystream to encrypt/decrypt a countersignature, ...

NEW
> ... for deriving a keystream to encrypt/decrypt a countersignature (see Section 4.2), ...

<==


It could be better clarified what the lifetime is of static-static DH keys (eg
that rejoining the group, a reboot, etc results in a new "long term" identifier
with respect to the static-static DH keys. I could not figure out from this
document whether there is any maximum keylife for these type of keys before a
rekey/rejoin event must happen.

==>MT

The lifetime of the static-static DH-keys is the same as the lifetime of the long-term authentication credentials of the peers.

The lifetime of the Pairwise Sender/Recipient Key is shorter, because other group keying material from the Security Context is used during their derivation (specifically, the Sender Key and Recipient Key). Practically, the lifetime of the pairwise keys is the same as that of the group keying material or of the long-term authentication credentials (whichever is shortest).

In order to clarify the above, we have revised the document as follows.

In Section 2.1.10, we have added the following 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 (emphasis mine)
> 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 14

        The key pair can, for example, be generated by the endpoint or
        provisioned during manufacturing.

I assume this key is only used for authenticating to Group Manager(s)
and not for the static-static DiffieHellman because that would be severely
lacking in forward security.

==>MT

The key pair supported by the authentication credential are used:

* To authenticate with the Group Manager.

* To authenticate with other group members when using the group mode (via a signature).

* To authenticate with other group members when using the pairwise mode.

On the latest point and building on the reply to the previous comment, the key pair is used only to derive a Diffie-Hellman shared secret.

In turn, the shared secret is only one input to the derivation of the pairwise keys that are effectively used to protect messages in pairwise mode. Another input is group keying material from the latest established Security Context.

Seen from another point of view and as clarified by the additional text in Section 2.5.1 (see the reply to the previous comment):

* The lifetime of the shared secret is the same as the lifetime of the asymmetric key pairs, which is the same as the lifetime of the authentication credentials.

* The lifetime of the pairwise keys is the shortest lifetime between that of: i) the long-term authentication credentials of the two endpoints deriving the pairwise keys; and ii) the latest established Sender Key on either of the two endpoints deriving the pairwise keys.

<==


        A possible way to ameliorate

Please find another word for "ameliorate". If I don't know this word, many more
people won't know what it means.

==>MT

We have rephrased as below.

OLD
> A possible way to ameliorate this issue ...

NEW
> A possible way to mitigate this issue ...

<==


        Randomness requirements for security are described in [RFC4086].

I think 4086 is very oudated and bad, and wouldn't mind not using it and
instead stating something about using proper cryptographic strength randomness
provided by the OS/hardware instead.

==>MT

We have simply removed that sentence and the reference to RFC 4086.

In fact, earlier text in the same paragraph already says that the Master Secret must have a good amount of randomness.

<==