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

[Ketan Talaulikar <[e-mail]>]

Hi Marco,

Thanks for that detailed explanation. I found it helpful and the document
looks good to me.

Thanks,
Ketan


On Fri, Dec 12, 2025 at 10:16 AM Marco Tiloca <[e-mail]> wrote:

> Hello Ketan,
>
> Thanks a lot for your review! Please find in line below our detailed reply
> to your comment.
>
> Thanks,
> /Marco
>
> ------------------------------
> *From:* Ketan Talaulikar via Datatracker <[e-mail]>
> *Sent:* Monday, October 13, 2025 2:15 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:* Ketan Talaulikar's No Objection on
> draft-ietf-core-oscore-groupcomm-27: (with COMMENT)
>
> Ketan Talaulikar 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%7C71ea933038fe43664f1d08de0a52256e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638959545084060536%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AXlag2Jx3WlNdni5Rz%2FO1T5w026MXd91KwP0G3BSbsU%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%7C71ea933038fe43664f1d08de0a52256e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638959545084081142%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fezdM2RdgD%2ByKfQ64pjp1ZU6%2B0FozLtF9QX0NUuF%2BOs%3D&reserved=0
> <https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to the authors and the WG for their work on this document.
>
> I have a question about the normative references that I am moving from
> DISCUSS
> to COMMENTS following a similar discussion with the rest of the IESG in a
> recent telechat:
>
> Why would the reference to an IANA registry COSE.Algorithms be a normative
> reference instead of an informative reference. I find the actual normative
> portions are in RFCs 8613, 5869, and 9053 - all of which are correctly
> categorized as normative. Isn't the pointer to the registry just an helpful
> reference for readers?
>
> ==>MT
>
> The reference is used in Section 2.1.2 "HKDF Algorithm", which says:
>
> > The HKDF Algorithm (see Section 3.1 of [RFC8613]) SHALL identify the
> used key derivation function, which MUST be one of the HMAC-based HKDF
> [RFC5869] algorithms defined for COSE (see Section 5.1 of [RFC9053]) and
> registered at [COSE.Algorithms].
>
> Going through the references included there:
>
> * RFC 8613 is included as related to the HKDF Algorithm parameter in the
> Common Context.
>
> * RFC 5869 is included as related to the HMAC-based HKDF construct as such.
>
> * RFC 9053 is included as related to the use of HMAC-based HKDF in COSE.
> In addition to that, it is sufficient specifically for HKDF SHA-256 and
> HKDF SHA-512, which are defined in that document.
>
> * The "COSE Algorithms" registry is included for generally taking into
> account future HMAC-based HKDF. It is needed that also such HKDF are
> specifically available for COSE, and an implementor has to check the
> registry in order to verify whether that is the case.
>
> Therefore, we believe that it is appropriate for the reference to the
> "COSE Algorithms" registry to be normative as well.
>
>
> For other algorithms that are also used in Group OSCORE (i.e., AEAD
> Algorithm, Group Encryption Algorithm, Signature Algorithm, and Pairwise
> Key Agreement Algorithm), they are also needed to be specifically available
> for COSE and therefore present in the "COSE Algorithms" registry.
>
> However, a normative reference to the "COSE Algorithms" registry is not
> really needed for those algorithms. (If any, an informative reference would
> be provided in the spirit of a simple pointer.)
>
> The reason is that, unlike for the HKDF Algorithm, all those four
> algorithms used in the group are indicated within the aad_array structure
> that is built to process a message with Group OSCORE (see Section 3.4). In
> particular, a specific algorithm is indicated by means of the corresponding
> identifier taken from "Value" field of the "COSE Algorithms" registry.
>
> That is, the need to correctly build the aad_array structure already
> requires the developer to look at the "COSE Algorithms" registry for
> picking up the correct algorithm identifiers. (At best, a normative
> reference here too would be redundant and superfluous.)
>
> <==
>
>
>