|
Hello Mališa,
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 -27 of the document.
Thanks,
/Marco
Marco Tiloca
Ph.D., Senior Researcher
Phone: +46 (0)70 60 46 501
RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)
Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity
https://www.ri.se
From: Mališa Vučinić via Datatracker <noreply@xxxxxxxx>
Sent: Tuesday, July 29, 2025 7:31 AM To: secdir@xxxxxxxx <secdir@xxxxxxxx> Cc: core@xxxxxxxx <core@xxxxxxxx>; draft-ietf-core-oscore-groupcomm.all@xxxxxxxx <draft-ietf-core-oscore-groupcomm.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> Subject: draft-ietf-core-oscore-groupcomm-26 ietf last call Secdir review Document: draft-ietf-core-oscore-groupcomm
Title: Group Object Security for Constrained RESTful Environments (Group OSCORE) Reviewer: Mališa Vučinić Review result: Ready 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. ==>MT
In Section 14.2 "Security of the Pairwise Mode", we have added:
* A new paragraph "Finally, the pairwise mode ensures group privacy ..."; and
* A numbered bullet list of security properties, analogous to the corresponding one provided for the group mode in Section 14.1.
We also took the opportunity to make a(n obvious) clarification in Section 14.1 "Security of the Group Mode", by explicitly mentioning that the Group Manager of a group is able to decrypt the messages protected with the group mode in that group, just like every
group member supporting the group mode.
<==
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. ==>MT
In Section 14.0 "Security Considerations", we have added a bullet list of properties that Group OSCORE does not meet, right before the last paragraph "The rest of this section ...".
<==
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
