Document: draft-ietf-core-oscore-groupcomm Title: Group Object Security for Constrained RESTful Environments (Group OSCORE) Reviewer: Patrik Fältström Review result: Almost Ready I have reviewed Group OSCORE document and have the following comments: 1. epoch : I have compared with MLS and find that (of course) TreeKEM or other ratchet algorithm is not chose (like in MLS) due to the limited devices. The sequence numbers in the form of epoch and sequence numbers is chosen. That said, I ask whether there is not a risk for replay attacks as messages does not include the epoch/gid and only include the window of acceptable sequence numbers? Specifically, if a receiver retains multiple epochs (e.g., during a rekeying transition), it might wrongly associate an old message with the current context. One solution could be to include the epoch (does not have to be the full gid) in the signature of the message. The epoch does not have to be transmitted, as the context within which the message is sent is known. Another solution could be to include the epoch as a CoAP option, and that way make it easier for a device to manage multiple coexisting epoch etc, have clear signalling if messages are received for the wrong epoch etc. 2. Credential lifecycle : I can not find any lifetime, expire or revocation information tied to the public keys. I understand the need for simple mechanisms here, but could not some data (like expiry) be encoded in the group context or bound to the Group Manager’s key provisioning? 3. Public Key Credential : I see the public key credentials (X.509 etc) discussed in a few locations. These might include Unicode code points and also compared in whatever protocol that consume the data. It is important that whatever is stored is opaque to the protocol. I.e. if X.509 data (DN for example) is stored there, there is no fuzzing around with data outside of what X.509 spec says. This includes sections like Signature verification mechanisms (3.3) that should be careful if comparison of unicode strings takes place. 4. Application payload : I also see some ability to have application payload of various sorts. This can be messy if it is not opaque (see (3) above). This is a mess in I18N context in the IETF and this document should stay away from trying to do something here. 5. Various byte fields : I see places like kid, kid context and such which are byte fields. Those should not be text, or treated as text, or compared as text (I hope). I did use ChatGPT and asked for a suggested text for (3), (4) and (5) and got the following: ========== Textual Encoding and Field Semantics All protocol-identifying fields used in Group OSCORE—such as Sender IDs (kid), Group Identifiers (GIDs), and Partial IVs (Sender Sequence Numbers)—are defined as opaque binary values (bstr). These fields must not be interpreted as text, Unicode or otherwise, and implementations must not apply encoding transformations, such as UTF-8 decoding or normalization, to their contents. Fields that may contain text—such as those found within authentication credentials (e.g., X.509 Distinguished Names, CWT claims, or JSON Web Key fields)—must be treated as opaque structured data, and interpreted only according to the rules of the credential format. Implementations must not attempt to reinterpret such fields outside of those specifications. This avoids misinterpretation, Unicode normalization attacks, or mismatches in identity comparison. In particular: - The kid and kid context fields are binary identifiers, not human-readable strings. - The Group Identifier (including the Epoch) is binary and defined for context lookup—not text or label data. - Any field that may contain Unicode characters (e.g., sub in a CWT, or CN in an X.509 certificate) must be processed according to the syntax, encoding, and comparison rules of that credential format (e.g., RFC 5280 for X.509). This strict separation between protocol fields and textual data is essential for consistent behavior across constrained implementations and secure identity handling. ========= Hope this helps. With regards, paf -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
