Document: draft-ietf-core-oscore-groupcomm Title: Group Object Security for Constrained RESTful Environments (Group OSCORE) Reviewer: Joerg Ott Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. Let me note up front that, for this tsv-art review, I am not able to read all accompanying documentation to understand all subtleties and mechanisms that may be provided elsewhere or obvious to those deep into OSCORE. The present I-D defines additions to security contexts in an OSCORE environment for the purpose of enabling secure multicast-based group communication paired with point-to-point messaging between group members. As such, the document mostly defines security mechanisms and only touches transport aspects in a few places. This tsv-art review naturally focuses on the latter. Section 8.1, 2nd para "Typically, the sender endpoint sends the message protected in pairwise mode over unicast [...]." This may be read to suggest that such requests could also be sent via multicast, which may not (or may?) be desirable. The two remaining paragraphs in section 8.1 don't help resolving this issue (actually, to me, they seem to create more questions than they answer). Section 12.1: "Communications that the Group Manager has with joining endpoints MUST be secured. Specific details on how to secure such communications are out of the scope of this document." Should one have the (normative?) reference to ietf-ace-key-groupcomm-oscore earlier and more explicit? Section 12.2, 2nd para states that "when possible, the delivery of rekeying messages should use a reliable transport [...]" This seems to suggest that an unreliable -- and possibly non-congestion controlled -- transport is fine, too. This appears risky if rapid membership changes occur or are suggested in some way as this could cause floods of rekeying messages. Especially since (4th para), "The Group Manager MUST rekey the group without undue delay when one or more endpoints leave the group." Since member may be evicted is they are suspicious, could such suspicion be caused by an adversary and thereby mount a flooding or denial of service attack? Let me finally not that the group manager is defined as an abstract concept, well, a function, to exercised by some entity inside or outside the group. This is a good abstraction but I am wondering where rendezvous mechanisms, which may or may not have transport and security implications, are defined. Would the group manager be (auto)configured? The group manager also appears as a single point of failure and neither this document not the referenced draft-ietf-ace-key-groupcomm-oscore-17 appears to discuss such aspects. Here, I may just miss the overarching context but it might appear useful to include some minimalist material to this end. As I wrote above, this may all be discussed or handled elsewhere. Nits: Section 12. intro: "According to a hierarchical approach, ..." -- reword? Section 12.2. 1st para: should -> SHOULD ? Best, Jörg -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
