Skip to main content

IETF Last Call Review of draft-ietf-core-oscore-groupcomm-26
review-ietf-core-oscore-groupcomm-26-secdir-lc-vucinic-2025-07-28-00

Request Review of draft-ietf-core-oscore-groupcomm
Requested revision No specific revision (document currently at 27)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-07-29
Requested 2025-07-08
Authors Marco Tiloca , Göran Selander , Francesca Palombini , John Preuß Mattsson , Rikard Höglund
I-D last updated 2025-10-09 (Latest revision 2025-09-12)
Completed reviews Genart IETF Last Call review of -26 by Paul Kyzivat (diff)
Artart IETF Last Call review of -26 by Patrik Fältström (diff)
Secdir IETF Last Call review of -26 by Mališa Vučinić (diff)
Tsvart IETF Last Call review of -26 by Joerg Ott (diff)
Tsvart Telechat review of -27 by Joerg Ott
Assignment Reviewer Mališa Vučinić
State Completed
Request IETF Last Call review on draft-ietf-core-oscore-groupcomm by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/v5zystmqJCLb7jgaLoNFjxXIao8
Reviewed revision 26 (document currently at 27)
Result Ready
Completed 2025-07-28
review-ietf-core-oscore-groupcomm-26-secdir-lc-vucinic-2025-07-28-00
I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The document specifies a group communication mode of OSCORE (RFC8613). As per
this document, the endpoints in a group can communicate using a “group” mode
and a “pairwise” mode. The group mode requests are source-authenticated using a
countersignature, while pairwise exchanges are symmetrically-protected using a
secret derived from a static-static DH key agreement algorithm. The document
reuses the elements of OSCORE and complements the processing with actions
dependent on the mode used.

The document is well written and thorough. The constructs used seem solid and
ensure the (nonce, key) pair uniqueness. Specifically on the Security
Considerations section, the section details a number of implications on
security and also details the security properties in group mode. One point I
would like to make is that the pairwise mode deserves a clear list of claimed
security properties, similar to how the group mode is discussed in Section
14.1. Also, it could perhaps be useful to discuss the security properties this
specification does not aim to meet, specifically in comparison with other
similar protocols like e.g. RFC9420.