Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm

[Esko Dijk <[e-mail]>]

Hi everyone,

I completed my review of draft-ietf-core-oscore-groupcomm for this 2nd last call. Below some points for discussion or clarification are listed. In another email today or tomorrow I'll send the editorial/textual/nit comments.
Overall my impression of the draft is good; there has been much attention to detail and guidance for the readers/implementers. Also its scope is set to support as many variations as possible (e.g. with/without pairwise mode, group mode, with/without Observe, Blockwise, supporting observation across rekeying events, etc.).  The downside of that is that the spec becomes complex at particular places to support all of that at the same time, securely. Maybe implementers will therefore consider to implement a subset only to avoid some of the complexity; which should be ok.

Best regards
Esko

--- 

1
"in order to protect the routing information of packets from observers"
-> this feels counter-intuitive; which routing information is protected by DTLS?  IP headers remain visible. Or is there more/other routing information protected by wrapping Group OSCORE messages in DTLS?

"but has the benefit of restricting the symmetric keying material while distributing only the public key of each group member."
-> can be formulated more clearly: in what way is the symmetric keying material restricted? E.g. do we mean restricting any given symmetric key to only those 2 CoAP endpoints that need to communicate using it. It is not restricted in the sense of restricted scope or, say, restricted (lower) key length.
  And 'while distributing only the public key of each group member' could be more specific also. To what other node(s) is the public key of a group member sent? E.g. only to those CoAP endpoints that need to communicate with that group member, not to 
all group members I think. 

1.1 Terminology
Perhaps the difference between "node" and "endpoint" can be reiterated here, even though it was defined by RFC 7252.  In this draft the 'term' node is often used e.g. in Section 3.2 to indicate a node with a single endpoint where that endpoint joins a group.  So when we talk about a 'node as a group member' that it means a single endpoint hosted on that node. Later in Section 3.2. it e.g. states endpoints are removed from the group which then excludes nodes from communication with the group. In case a node can host multiple endpoints, we may need to say then that all endpoints of a particular node need to be removed from the group. (Assuming it can have multiple like defined by RFC 7252.) So then it becomes important for security reasons to get the distinction clear.

2.3 / 2.4.1
Section 2.3 discusses format requirements for public keys. It also says "For example, an X.509 certificate is provided as its direct binary serialization." which was quite confusing to me as it suggests the entire certificate is denoted as a "pubic key" and used as such in 2.4.1 procedures.
Does this mean in Section 2.4.1 the entire X.509 certificate is used to derive the pairwise key? That seems less efficient as a node then has to store the entire X.509 certificate of each peer, instead of just the public-key part of it (the SubjectPublicKeyInfo structure). That will take more memory than perhaps needed.
Maybe there's some reason the full certificate is used and not just the SubjectPublicKeyInfo part of it? It could avoid further parsing of the certificate structure.  Also when only a part is used it needs to be really clearly defined to avoid unclarities about what part to really use (as we had in the ANIMA WG).
And another thought: besides memory impact, would using the full X.509 be more overhead on a constrained device instead of just the SubjectPublicKeyInfo part of it? I.e. the input to the HKDF(.) is substantially longer when using the full cert. 

2.4.1
the adjective "(signature)" is used a couple of times. I don't see a "signature public key" being defined explicitly. Also Fig 1 does not use "(signature)". Do I miss something?

3.2
See Section 1.1 comment.

"The Group Manager MUST check if the new Gid to be distributed coincides with the Birth Gid of any of the current group members"
-> This is unclear to me. In the first paragraph of 3.2, it is stated that GM creates a new Gid. So how could it coincide if it is really new? (Also not clear what 'coincide' means here. Equal? If so, we should write 'equals')
-> What is the purpose of evicting the elder members?  This is puzzling, as the aim is to keep the elder members in the group surely.

3.2.1

	Even when an endpoint joining a group is recognized as a current
	   member of that group, e.g., through the ongoing secure communication
	   association, the Group Manager MUST assign a new Sender ID different
	   than the one currently used by the endpoint in the group, unless the
	   group is rekeyed first and a new Gid value is established.
-> How can an already-joined endpoint, i.e. a member, join the same group?  Or does this text assume that the GM knows the endpoint is a member while the endpoint itself "forgot" this or purposely deleted its group-related data to do a re-join?
Section 3.3 step 6 has the same question.

Figure 2 says "After changing Group ID, an unused kid can be assigned". Do we mean here a previously used kid (under a Gid=N) that is currently unused (under Gid=N), can be re-assigned after Gid change to Gid != N ?  Not sure whether we can fit the intended sentence in such a small space. Maybe "After Group ID change, a formerly used kid can be re-used" ?

8
Recommendations in the last paragraph to not send back any error message: is this also applicable when the group request is sent over a unicast transport? In that case it should be ok to respond error, since there's no risk of amplification attack.
E.g. for a unicast pairwise request it is defined that an error can be sent e.g. in 9.4.  Although sending group request over unicast is generally not recommended as stated elsewhere in the draft, there were some valid cases cited so we can consider group request over unicast cases.

8.3.1
"For each ongoing observation, the server can help the client to
   synchronize, by including also the 'kid context' parameter in
   notifications following a group rekeying, "
-> I'm wondering in what way this helps. Is it a reduction of time / energy used by the client, because sending it lets the client avoid trying out decryption/validation using first the old Gid/context, which would fail?
The downside of optionally including it is a more complex handling in the code i.e. more message variations = more code paths = more things potentially going wrong and to test.

10

	Constrained IoT devices may alternatively represent Montgomery curves
	   and (twisted) Edwards curves [RFC7748] in the short-Weierstrass form
	   Wei25519, with which the algorithms ECDSA25519 and ECDH25519 can be
	   used for signature operations and Diffie-Hellman secret calculation,
	   respectively [I-D.ietf-lwig-curve-representations].

-> This sounds optional ('may'). But the paragraph is in the section "Mandatory-to-Implement"; why place it there?
-> Also several SHOULD/RECOMMENDED items are in this section.  Same question, doesn't it contradict the title?

11
I did not find a consideration about selecting the value/length of the Master Salt, and whether it needs to be set at all (i.e. other than the default value of Master Salt). Is it useful for group communication? In what situations?

What about a consideration on a possible DoS attack:  an attacker first blocks the IP communication path to the Group Manager , and then trigger a mass power-cycle (reboot) including devices that are doing Group OSCORE communication. These device will then not perform group communication anymore due to the section 2.5.1.1 requirements last paragraph.   Blocking the IP communication path to the GM could be done e.g. by injecting fake DNS responses for GM hostname queries or by removing a network link that's used for routing towards the GM. At least in the movies an attacker is ocassionally able to trigger a power outage for a few seconds  ;) 

11.1
"Thus, a current group member owning the
      latest group keying material does not own the public key of any
      former group member."
-> Not sure what this intends to say. A group member may store a public key of any group member. But it never "owns" the public key of another node, in the sense that it doesn't have access to its private key right?
Maybe it was intended to say that due to protocol/GM design, a node doesn't store the public key of a former group member because it gets deleted at the moment that the member leaves.
Changing "owned" to "stored" may help to rephrase.

11.7.2
Towards the end the reader may lose a bit the context of the prior "would" statements. E.g. we have:

	Since the Partial IV is 5 bytes in size, this requires 2^40
	   operations to test all the Partial IVs, which can be done in real-
	   time.  The probability that a single given message M1 can be used to
	   forge a response M2 for a given request would be equal to 2^-24,
	   since there are more MAC values (8 bytes in size) than Partial IV
	   values (5 bytes in size).

Is this in the context of the present solution specified, or in context of a hypothetical case of a countersignature that does *not* cover the OSCORE Option?
Same question for the paragraph:
	Note that, by changing the Partial IV as discussed above, any member
	   of G1 would also be able to forge a valid signed response message M2
	   to be injected in the same group G1.
(In other words: do we want to say here that a member of G2 can *not* forge a valid signed response message M2, because we now have a countersignature that covers the OSCORE Option?
Or do we want to say that a member of G2 *can* forge in real-time.)

References
Quite a number of references are informative. This may need to be changed for some, based on the guidelines in https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/. 

Reference [I-D.mattsson-cfrg-det-sigs-with-noise] is used in a normative requirement (SHOULD), so the reference should be normative even though some implementations may not use it.  (Assumption here is that most will.)
Similar for [I-D.ietf-ace-key-groupcomm-oscore],    [I-D.ietf-ace-key-groupcomm-oscore]: used in a SHOULD.
CoAP Observe RFC 7641 plays an important role so should be a normative reference.  That is true regardless of the fact that Observe is an optional feature; since many of the sections define specific protocol elements for Observe i.e. it defines new technology that builds normatively on Observe.

Reference [I-D.ietf-core-echo-request-tag] is used in a normative MUST requirement (in 2.5.1.2), so here the reference should be normative.
Or do I misunderstand this? It can also be interpreted as only Appendix E being the target of the MUST requirement, while [I-D.ietf-core-echo-request-tag] is only informative - but that seems to be not the case, as the format of the Echo option is actually used in the Appendix E approach. In other words you need to read [I-D.ietf-core-echo-request-tag] definitions to implement the solution of Appendix E and it cannot work otherwise. 

Appendices
All: Some appendices have normative language; so it seems they are not merely informative. Is there a particular reason for putting this information in an appendix and not in main text?
Should we indicate in the introduction which Appendices are normative and which informative?

Appendix A.1
"Multicast data security ciphersuite: all members of a security group must agree on a ciphersuite"
-> Isn't it determined by the GM? E.g. the GM needs to establish a ciphersuite that all members can support. There's no agreement protocol or so.

Appendix D
	It is RECOMMENDED that the join process adopts the approach described
	   in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework
	   for Authentication and Authorization in constrained environments
	   [I-D.ietf-ace-oauth-authz].
-> the part "and based on the ACE framework ..." is not so clear. Is applying [I-D.ietf-ace-oauth-authz] RECOMMENDED? Or is it just informational saying that [I-D.ietf-ace-key-groupcomm-oscore] is basing itself on [I-D.ietf-ace-oauth-authz], as a "FYI" statement? Section 3 language on this same subject is more clear and could be used instead.  Or maybe refer to the Section 3 statement from here to avoid duplication.

Appendix E
Given the normative-references discussion above and normative references made to Appendix E, why isn't this content in a main document section?


-----Original Message-----
From: core <[e-mail]> On Behalf Of Jaime Jiménez
Sent: Tuesday, November 9, 2021 20:00
To: [e-mail]
Cc: [e-mail]
Subject: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm

Dear CoRE,

as we discussed yesterday, the authors of draft-ietf-core-oscore-groupcomm think their draft is ready for a 2nd WGLC. The current version of the draft (v13) is not expecting any updates so you can start your planned reviews.

https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-13

In addition to the email list discussion reviewers could consider opening new issues on the Github repo of the draft as courtesy to the authors.

https://github.com/core-wg/oscore-groupcomm

As we have the IETF ongoing and the document needs time to be digested, we place the end of the call on the 1st of December with a possibility of extension depending on the number of reviews.

>From the minutes I take that CA, RH, ED and TF would give it thorough look. Thank you already for that, much appreciated!!

Ciao!
-- 
Jaime Jiménez

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core