[core] I-D Action: draft-ietf-core-groupcomm-bis-09.txt

[John Mattsson <[e-mail]>]

Review of draft-ietf-core-groupcomm-bis-09

Hi,

Below is my review of draft-ietf-core-groupcomm-bis-09. The document seems “ready with issues”.


  *   Abstract says, "replaces RFC 7390". Replaces is not a formal IETF term, maybe change to obsoletes or "replaces and obsoletes" as in the introduction.



  *   Figure 1 and Section 2.2.1.1 seems to be saying different things.

2.2.1.1 states that host subcomponent is mandatory and that IP multicast address and UDP port number are optional. Figure 1 states that IP multicast address and UDP port number are mandatory.



  *   group1.com and alias.com are real domain names in use and not suitable for examples. I think you should use one of the example domains example.com, example.net, example.org, xample.edu, or .example



  *   ”However, using such experimental protocol is not a recommended approach.”

I don’t think something is not recommended just because it is an experimental RFC. What would the alternative be? To use something proprietary that is not even documented publicly.


  *   “It has to be separately enforced by leveraging the resource properties or through dedicated access control credentials assessed by separate means.” feels a bit strong. For a very simple system with a single resource, I think it is ok to use group membership. “It should be separately enforced” is probably better.


  *   "GROUPNAME" does not seem like a good name for the application group name as you define three types of groups with all might have “names". I suggest changing to APPNAME or something. In general, it might be good to use the work “group” less and the terms “CoAP group”, “multicast group”, “application group”, and “security group” more.


  *   The beginning “A security group is identified by a stable and invariant string used as a group name”.
How to identity the group in the management system is probably best left for implementation, or do you mean something Group OSCORE specific here? Is having a group name mandatory in general? Maybe I want to use an integer?



  *   The figures in Appendix D would look a lot nicer with aasvg.


  *   “For example, early discovery of devices and resources is a typical use case where the NoSec mode is relevant” seems like something people say to move the hard problem of secure credential management somewhere out of scope. Is there any _concrete_ examples of any secure actual deployments where this message flow makes sense? Otherwise, I think this part should be removed.



  *   ”For sensitive and mission-critical applications”. I think the current IETF view should be at least ”Unless proven to be not sensitive”. Zero trust mandates encryption everywhere without exceptions and modern protocols like QUIC delivers that.


  *   ”Group policies should”

”That is, it may”

Should these be capital MAY and SHOULD? Agree that rekeying policies is best left for the applications. Section 6.2.1 should mention that the security requirements can vary between applications and also depending on ”who” is joining or leaving the group.


  *   ”source authentication”

“SHOULD NOT accept group requests that can not be authenticated in some way”

“is indeed reachable at the claimed source address”

I think it would be good to explain better to the reader that there are two difference “source”. Group OSCORE does not give any guarantees about the source address, and ECHO does not give source authentication.



  *   I think it should be stated that NoSec servers MUST NOT be accessible through the public Internet due to amplification attacks. A group of multicast servers may otherwise be accessible via a gateway from the Internet.

Editorial
----------------


  *   Several abbreviations like UML, HVAC should be spelled out.


  *   "TCP, TLS and WebSockets"
            "named, created, discovered and maintained"
            "manages, renews and provides "
            "specific, narrow and well"
            "GET, FETCH or POST"
            ... and more

IETF uses the Oxford comma.


  *   OLD "commmunication"
            NEW "communication"


  *   OLD "Different types of group"
            NEW "Different types of groups"


  *   OLD "can not"
            NEW "cannot"


  *   OLD "amplication"
            NEW "amplification"


  *   OLD "interecting"
            NEW "interacting"


  *   OLD "i.e,"
            NEW "i.e.,"


  *   OLD "e.g,"
            NEW "e.g.,"

Cheers,
John