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

[Deb Cooley <[e-mail]>]

Thanks for this.  I went back through the draft.  My responses are in line
w/ [DC]

Deb

On Fri, Dec 12, 2025 at 1:53 PM Marco Tiloca <[e-mail]> wrote:

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

[DC] there is terminology at your disposal.  'key agreement' is normally
associated with (EC)DH.  'symmetric keys' are usually associated with
algorithms like AES and CHACHA.  and signature/authentication is associated
with ECDSA/EdDSA.

>
>
> 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.
>
> <==
>
[DC]  this is fine, but at some point you all will need to modernize the
language (to be less offensive).  Do it now, or do it later.  It is your
choice.


>
>
> 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).
>
> <==
>
[DC]  the fact is the same sentence is used in both Section 2 and Section
2.1.5.  I'm not sure what clarity you get from that.  2.1.5 certainly
doesn't actually specify the format of auth creds used in the group.


>
>
> 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 ...
>
> <==
>
[DC] it is still confusing.  Perhaps using the phrase 'symmetric key' might
help?  Define the thing named 'Signature Encryption Key' as a symmetric key
that is used to encrypt signatures (or counter signatures).


>
>
> 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.
>
> <==
>
[DC]  so complicated.  This leads me to more questions:
1.  Where do the initial Sender and Recipient keys come from? [ out of
scope?]
2.  Calling the Sender/Recipient keys salts is a little misleading.
3.  Let me see if I understand what you are doing.  You are using the
previous Sender or Recipient keys to derive the next Sender and Recipient
keys? So Sender Key (v1) = HKDF(Sender Key(v0), IKM-Sender, info, L) where
only the Sender Key changes (because the auth creds, shared secret, info
and L don't change). Same is true for Recipient key construction.  So as
long as I don't have 'Sender Key (v0)' the whole construction is ok. But
these are symmetric keys, so everyone the Sender communicates with has to
have that key?  Which means that anyone 'in the club' can spin to the next
Sender key?  What am I missing?


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

[DC]  I'm happy you are willing to remove CBC mode.  And obviously CTR mode
can be used w/ a nonce, but that certainly reduces the space for the
counter.  A 4 byte counter will roll over more often which means you will
need hard limits.  If your nonce is smaller, the counter can be bigger,
allowing more data to traverse before you have to rekey.  Obviously there
are tradeoffs.


>
>
> 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.
>
> <==
>
[DC] better!


>
>
> 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.
>
> <==
>
[DC]  ok


>
>
> 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.
>
> <==
>
[DC]  ok