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

[Deb Cooley <[e-mail]>]

Top posting:

These responses are fine.

This made me chuckle:  "the symmetric key for deriving a keystream to
encrypt/decrypt" vice just calling it "the symmetric key that is used to
encrypt".  They mean the same thing (keystream mod-2 added to plaintext
*is* encryption, and is what AES-CTR mode uses), but the first is more
complicated.    But I'm not interested in pushing this point as it is
merely semantics and readability.

As for key chaining:  All the keys used in this scheme (especially as you
are reusing keys for both key agreement and signature, for possibly
indefinite lengths of time) should be carefully mapped out.  The goal is to
ensure that you indeed don't have a situation where if I know some key
early in the lifetime, I can generate every subsequent key.  Without going
back to the initial specifications, it is difficult to track where
generating 'a good amount of randomness' (as specified in RFC 8613, section
12.3) occurs and determining if that is 'sufficient' for however
long/varied the use is.  Again, I leave this as an exercise for the authors
(who are more than capable of doing this analysis).

In the end my comments were 'no obj', so I'm certainly not blocking
publication.

Deb

On Wed, Dec 17, 2025 at 4:05 PM Marco Tiloca <[e-mail]> wrote:

> Hello Deb,
>
> Thanks for your follow-up comments.
>
> Please find inline below our replies to the points still open, starting
> with "==>MT2".
>
> We have also updated the same GitHub PR accordingly.
>
> Best,
> /Marco
>
>
> ------------------------------
> *From:* Deb Cooley <[e-mail]>
> *Sent:* Tuesday, December 16, 2025 9:09 PM
> *To:* Marco Tiloca <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]
> <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>
> *Subject:* Re: Deb Cooley's No Objection on
> draft-ietf-core-oscore-groupcomm-27: (with COMMENT)
>
> 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.
>
> ==>MT2
>
> Indeed we have used that terminology when addressing the main later
> comment about this point, by rephrasing the text in Sections 2.5 and 8.
>
> <==
>
>
>
> 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.
>
> ==>MT2
>
> After addressing the original comment, the text became as below.
>
> Section 2.0:
> > 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.1.5 (as the whole content of the section):
> > The new parameter Authentication Credential Format specifies the format
> of authentication credentials used in the group. Further details on
> authentication credentials are compiled in Section 2.4.
>
>
> The original comment was also about avoiding a "double reference", i.e.,
> the chain of references Section 2.0 --> Section 2.1.5 --> Section 2.4.
>
> Aligned with the comment, we keep the latest text in Section 2.0 as above
> but we have now also shortened the text in Section 2.1.5 by removing its
> second sentence, as below:
>
> NEW (Section 2.1.5, as the whole content of the section)
> > The new parameter Authentication Credential Format specifies the format
> of authentication credentials used in the group.
>
> As a result, the bullet point in Section 2.0 keeps both forward references
> to Section 2.1.5 and Section 2.4, and there is no "double reference"
> anymore.
>
> Admittedly, there is little to say about the parameter Authentication
> Credential Format as such in Section 2.1.5. However, the editorial intent
> that we would like to preserve is to have:
>
> * The bullet list of Section 2.0 giving a heads-up on new parameters of
> the Security Context, with forward references to the corresponding sections.
>
> * Section 2.1 including a Section 2.1.x for each parameter of the Common
> Context.
>
> <==
>
>
>
>
>
> 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).
>
> ==>MT2
>
> Right, it is good to call it "symmetric key".
>
> At the same time, we think that we should also keep saying that the key is
> used to derive a keystream. The keystream is actually used for
> encrypting/decrypting a countersignature. This is also consistent with the
> later text about the Signature Encryption Key in Section 2.1.9.
>
> We have updated the rephrased text as below:
>
> OLD (Section 2.0)
> > Signature Encryption Key, used for encrypting and decrypting the
> countersignature of messages protected in group mode (see Section 2.1.9).
>
> NEW (Section 2.0)
> > Signature Encryption Key, specifying the symmetric key used for deriving
> a keystream, which is in turn used for encrypting and decrypting the
> countersignature of messages protected in group mode (see Section 2.1.9).
>
> OLD (Section 2.1.9)
> > The new parameter Signature Encryption Key specifies the encryption key
> for deriving a keystream to encrypt/decrypt a countersignature, when a
> message is protected in group mode (see Section 7).
>
> NEW (Section 2.1.9)
> > The new parameter Signature Encryption Key specifies the symmetric key
> for deriving a keystream to encrypt/decrypt a countersignature, when a
> message is protected in group mode (see Section 7).
>
> <==
>
>
>
>
>
> 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?
>
> ==>MT2
>
> Please see below our answers to the three questions separately.
>
> The main red thread is: "Sender/Recipient Keys" and "Pairwise
> Sender/Recipient Keys" are two different things, and there is no key
> chaining involved.
>
>
> 1. As described in Section 2.3 of the present document, Sender/Recipient
> Keys are derived using HKDF like in OSCORE (see Section 3.2.1 of RFC 8613),
> with a minor modification about the algorithm identifier to refer to during
> key derivation.
>
>    Note that the Sender/Recipient Keys of a given "epoch" are not related
> to the Sender/Recipient Keys of any other epoch. A new epoch starts when
> the Group Manager establishes a new Security Context in the group, which
> consists of a new Master Secret with a good amount of randomness (see
> Section 14.11) and a new Group ID. That information is taken as input by
> the group members for deriving new Sender/Recipient Keys.
>
>    Consistent with the above, Section 2 of the present document defines
> only the extension to the Security Context defined in RFC 8613.
>
>    Concepts that are inherited from OSCORE also include:
>
>    * The Sender Key of an endpoint, stored in that endpoint's Sender
> Context.
>
>    * The Recipient Key of an endpoint, stored in that endpoint's Recipient
> Context associated with another endpoint in the group. (In Group OSCORE,
> there are multiple Recipient Contexts within the same Security Context)
>
>    * The derivation of Sender/Recipient Keys, using the same construct
> defined in Section 3.2.1 of RFC 8613 and based on HKDF.
>
>
> 2. To be precise, they are not "called" salt. In Section 2.5.1, the
> document says (emphasis mine):
>
>    > The Sender Key from the Sender Context is **used as salt** in the
> HKDF, when deriving the Pairwise Sender Key.
>
>    and
>
>    > The Recipient Key from the Recipient Context associated with endpoint
> X is **used as salt** in the HKDF, when deriving the Pairwise Recipient Key.
>
>    This is consistent with the interface of HKDF (RFC 5869) that is used
> for key derivation in RFC 8613 and is inherited in Section 2.5.1 of the
> present document for deriving the Pairwise Sender/Recipient Keys.
>
>    In particular, the Sender/Recipient Keys are used as the first argument
> of HKDF, which is called "salt". Hence, those keys "are used as salt" for
> HKDF. We are simply mapping Group OSCORE parameters/information with
> arguments of HKDF.
>
>    If the group is rekeyed, then the Sender/Recipient Keys change (see
> above). Hence, using the new Sender/Recipient Keys as salt input of HKDF,
> two endpoints derive different Pairwise Sender/Recipient keys, even though
> keeping the same Diffie-Hellman shared secret that is used as part of the
> IKM input of HKDF.
>
>
> 3. Please note that "Sender/Recipient Keys" and "Pairwise Sender/Recipient
> Keys" are two different things, and that there is no key chaining involved.
>
>    When defining the derivation of Pairwise Sender/Recipient Keys and
> discussing the different inputs/outputs, Section 2.5.1 also presents the
> different keys in different bullet points.
>
>    * Sender/Recipient Keys are used to protect messages in group mode that
> are exchanged within the group at large.
>
>      New Sender/Recipient Keys are not derived from past Sender/Recipient
> Keys, i.e., there is no key chaining.
>
>      Rather, the latest Sender/Recipient Keys are derived from the latest
> Security Context, i.e., using the same construct from OSCORE (see Section
> 3.2.1 of RFC 8613). Among other things, this takes as input the latest
> Master Secret and Group ID that the Group Manager has generated and
> distributed.
>
>      Rekeying the group results in deriving new Sender/Recipient Keys.
>
>    * Pairwise Sender/Recipient Keys are totally different keys, and are
> used to protect messages in pairwise mode that are exchanged between
> exactly two peers.
>
>      New Pairwise Sender/Recipient Keys are not derived from past Pairwise
> Sender/Recipient Keys, i.e., there is no key chaining.
>
>      Rather, the latest Pairwise Sender/Recipient Keys are derived as
> defined in Section 2.5.1 of the present document.
>
>      Rekeying the group results in deriving new Sender/Recipient Keys,
> hence in deriving new Pairwise Sender/Recipient Keys by taking the new
> Sender/Recipient Keys as salt input of HKDF.
>
>      Alternatively, a change in two peers' authentication credentials
> results in a change of their Diffie-Hellman shared secret, hence in
> deriving new Pairwise Sender/Recipient Keys by using that Diffie-Hellman
> shared secret as part of the IKM input of HKDF.
>
> <==
>
>
>
>
>
> 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.
>
> ==>MT2
>
> The length of the counter indeed introduces a tradeoff here, although a
> different one.
>
> In the construct based on AES-CTR that we have defined, the size of the
> counter plays no direct role in the frequency of rekeying. As also
> explained below, the hard limit on its value has other implications.
>
> Based on the new text for Section 2.1.7 when using AES-CTR:
>
> * Given a plaintext/ciphertext, the 16-byte IV for AES-CTR is built by
> concatenating a 12-byte nonce generated as in Section 3.3 and the 4-byte
> counter with value 0 (i.e., 0x00000000). The IV is used when processing the
> first block of the plaintext/ciphertext.
>
> * When processing a plaintext/ciphertext, (IV + i) is used to process the
> i-th block (i = 0, 1, 2, ...). In the document, we are deliberately not
> describing the increment of the IV (i.e., of the 4-byte counter in our
> case) at each block processing, in order to not repeat what is already
> defined in Section 4 of RFC 9459.
>
> * To avoid a wrap-around of the counter (which would lead to reusing the
> same IV with the same key), the 4-byte length of the counter poses a hard
> limit on the length of the plaintext/ciphertext that can be processed,
> which is stated to be 64 GB in the new text. In this respect, we think that
> having the nonce of 12 bytes in length and the counter of 4 bytes in length
> is a good tradeoff.
>
> * The nonce generation construct in Section 3.3 ensures that, given a key,
> a different nonce is used for processing each plaintext/ciphertext.
> Therefore, it is ensured that, given a key, a different IV is used for
> processing each plaintext/ciphertext, and a different (IV + i) is used for
> processing each block of a plaintext/ciphertext.
>
> <==
>
>
>
>
> 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
>
>