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

[Marco Tiloca <[e-mail]>]

Hi Esko,

On 2022-03-09 11:11, Esko Dijk wrote:
> Hi Marco,
>
> Thanks for your considered updates and detailed responses. I didn't follow the details of how the document evolved based on the review comments.
> If there's anything you need my input on, please let me know.  Your proposals look okay to me.

==>MT
Great to hear, and thank you again for the good and in-depth review!
<==

>
> One comment on the re-using of GID values: based on your reply, it looks like re-use of GIDs may be common in some implementations (e.g. when using the small Group Epoch number space of 16 bits like in Appendix C, in the GID).
> If that's the case then we can't really avoid the complexities associated to GID re-use, which we rather would want to avoid by just picking a sufficiently large GID number space that never runs out.
> In case we think that GID re-use should still be a rare case / corner case, then it would be better to handle the complexity of this in a separate section that we can point to. This section can then include the details like eviction of elder members.   Then it avoids all that complexity for implementers who only use a "GIDs are never re-used" type of solution.

==>MT

TL;DR: Could you please check the latest Section 3.2.1.1 [1] and see if 
it already addresses your comment in this mail?


The original proposal in the old mail below was a high-level starting 
point. When revising the draft, I tried to put together that direction 
and what was further agreed at the interim meeting on 2022-01-19.

The conclusion was to make the recycling of GIDs optional to support for 
the Group Manager. While recycling GIDs has an impact on the group 
lifetime, it does not have an impact on the implementation of group 
members. That is, if supported, it's all on the Group Manager.

I am not sure we have/need to take a particular stance about GID 
exhaustion being a rare or common event, or about being rare or common 
for a Group Manager to be able to handle it through GID recycling. On 
the other hand, we are discussing the exhaustion issue as such and 
presenting an optional solution to adopt.

More practically, in the latest version -14 of the draft, the topic of 
GID recycling has been in fact concentrated in the single dedicated 
Section 3.2.1.1 [1].

The first two paragraphs discuss the possible exhaustion of GIDs in 
general, as also affected by the used format and size. Then, as 
described right after, upon GID exhaustion the Group Manager can simply 
terminate the group or, optionally, use the originally proposed 
recycling approach now presented in this section only.

So, the intent of this new Section 3.2.1.1 was indeed to provide a well 
circumscribed description of the GID exhaustion and of their recycling 
as an optional feature for the Group Manager. In particular, unlike in 
previous versions of the draft, now the main management procedures of 
Section 3.2.0 do not mention the issue and possible solutions as 
interspersed text anymore.

Best,
/Marco


[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-14#section-3.2.1.1

<==

>
> Best regards
> Esko
>
> -----Original Message-----
> From: Marco Tiloca <[e-mail]>
> Sent: Wednesday, January 19, 2022 12:06
> To: Esko Dijk <[e-mail]>; Jaime Jiménez <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm
>
> Hi Esko,
>
> Thank you very much again for you review!
>
> Please, find detailed replies inline.
>
> Best,
> /Marco
>
> On 2022-01-11 10:14, Esko Dijk wrote:
>> 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?
> ==>MT
> The wording "routing information" was suggested by Jim in an old review.
> This refers to CoAP options such as Uri-Host, Uri-Port and Proxy-Uri,
> which would not be protected by (Group) OSCORE but would be protected by
> DTLS.
>
>
> PROPOSAL: Rephrase as follows.
>
> OLD:
> "... (and vice versa), in order to protect the routing information of
> packets from observers."
>
> NEW:
> "... (and vice versa). This prevents observers from accessing addressing
> information conveyed in CoAP options that would not be protected by
> Group OSCORE, but would be protected by DTLS. These options include
> Uri-Host, Uri-Port and Proxy-Uri.
> <==
>
>> "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.
> ==>MT
> On the first point, the restriction is not about the scope of key usage
> or about key length. It is about the amount of symmetric material to
> distribute. Rather than distributing (at most) one symmetric key per
> other group member, the Group Manager provides one shared Master Secret
> and (at most) one public key per group member.
>
> On the second point, the distribution of public keys to a certain node X
> can basically happen at two points in time: when X (re-)joins the group
> or when X asks the Group Manager for other members' public keys while
> already a group member. In either case, X can, e.g., ask for the public
> keys of all group members, or specify some filter criteria to obtain the
> public keys of only some members.
>
> These details related to key distribution are intentionally out of scope
> for Group OSCORE. In the approach defined in
> draft-ietf-ace-key-groupcomm-oscore  all such details are also defined.
>
>
> PROPOSAL: In order to address this comment while not getting into key
> distribution details, we can rephrase as follows.
>
>
> OLD:
> "... it is desirable to restrict the provisioned keying material."
>
> NEW:
> "... it is desirable to restrict the amount of secret keying material
> provided to each node."
>
>
> OLD:
> "... (see Section 3), but has the benefit of restricting the symmetric
> keying material while distributing only the public key of each group
> member."
>
> NEW
> "... (see Section 3). However, it has the benefit of distributing a
> single shared secret, while distributing only the public keys of group
> members or a subset of those."
>
> <==
>
>> 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.
> ==>MT
> Good points. I see this comment as twofold.
>
> On the first part, looking at RFC 8613, OSCORE always uses "endpoint"
> for what concerns the actual security protocol. Instead, it uses "node"
> only for "constrained node", "intermediary node" or "next node".
>
> The occurrences of "node" that you found can be better replaced by
> "member" or "endpoint" (depending on the context). Note that a group
> member is actually an "endpoint". In fact, Sender IDs assigned to group
> members are first of all defined by OSCORE as associated to endpoints.
>
> Related fixes are:
>
> Section 1: s/number of nodes/number of endpoints
> (note "endpoints" rather than "members" here, thus taking into account
> both current group members and candidate group members that still have
> to join)
>
> Section 3.1: s/When a node (re-)joins a group/When an endpoint
> (re-)joins a group
>
> Section 3.1: s/the Birth Gid of that node/the Birth Gid of that endpoint
>
> Section 3.1: s/In case the node has in fact/In case the endpoint has in fact
>
> Section 3.1: s/Upon nodes' joining/Upon endpoints' joining
>
> Section 3.2: s/this excludes such nodes/this excludes such endpoints
> (this would also be consistent with the previous sentence of the section)
>
> Section 11.1: s/in case of nodes' leaving/in case of members' leaving
>
> I couldn't find other ambiguous uses of "node" and "endpoint".
>
>
> On the second part, yes, a node might admit multiple endpoints, say E1
> and E2, which thus would have separately joined the group as distinct
> group members. The eviction of E1 as compromised does not necessarily
> mean that E2 is also compromised and to be evicted.
>
>
> PROPOSAL: Perform the fixes and rephrasing above. In Section 3.2, we can
> clarify that if a *node* is detected to be compromised, the Group
> Manager must evict all the group members corresponding to endpoints
> "living" in that node.
> <==
>
>> 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.
> ==>MT
> Yes, you understood correctly, the whole X.509 certificate and its
> serialization would be stored and used for the process you mention.
>
> What follows relates to the three different parts of the comments.
>
> 1) Yes, the current text denotes the entire certificate as the "public key".
>
>      To avoid any confusion, we can follow more closely the same
> terminology used in draft-ietf-lake-edhoc , and use "authentication
> credential" to denote X.509 or C509 certificates, CWT, and CCS.
>
>      Then an "authentication credential" includes a "public key" as
> authentication key, with details depending on the type of
> "authentication credential".
>
>      That said, the whole "authentication credentials" are currently
> used: i) to derive pairwise keys, see Section 2.4.1, on which process a
> security proof has been accordingly produced in [Thormarker]; and ii) to
> fill the external_aad structure, see Section 4.3.
>
>      Instead, the "public key" alone is used: i) to compute a
> Diffie-Hellman shared secret to derive pairwise keys, see Section
> 2.4.1.; and ii) to verify the signature of incoming messages protected
> in group mode, see Sections 8.2 and 8.4.
>
>
>      PROPOSAL: The document can be revised to consistently use
> "authentication credential" or "public key" as above.
>
>
> 2) On considering the whole "authentication credentials" verbatim as per
> the previous point, this has been aligned to draft-ietf-lake-edhoc.
>
>      While considering that "authentication credentials" are involved in
> key derivation (i.e., of pairwise keys) and in structures providing
> secure message binding (i.e., the external_aad), there are reasons to
> consider keeping them verbatim.
>
>      * It ensures to carry on also metadata and parameters related to the
> public key. These include not only the public key algorithm (that would
> indeed be, e.g., in the SubjectPublicKeyInfo structure of an X.509
> certificate), but also other relevant pieces of information (if present)
> such as key usage, expiration time, issuer and subject.
>
>      * It ensures that all endpoints using another endpoint's
> "authentication credential" handle exactly the same bytes, as obtained
> by the credential provider (e.g., the OSCORE Group Manager) and as
> crafted by the original credential issuer.
>
>      Sure, this simplicity introduces the cost of storing the whole
> "authentication credential" as a larger object, also after having
> successfully validated it. However, not doing that and rather preserving
> only a subset of its content, would result in different complications.
>
>      * For each type of current and future "authentication credential",
> it becomes necessary to define the exact subset of information to be
> extracted and preserved. This subset must be kept up to date if a type
> of "authentication credential" is extended in the future.
>
>      * For each type of current and future "authentication credential",
> it becomes necessary to define the exact canonical way to encode such a
> subset, in order to ensure that all endpoints converge to the same result.
>
>      This is a trade-off between storage on one hand, and
> complexity/feasibility/flexibility in correctly handling "authentication
> credentials" (which, in the future, can be extended or newly introduced).
>
>      Personally, I tend to favor the latter, while seeing the former as
> an incentive to prefer more compact types of "authentication
> credential", especially in large groups.
>
>
>      PROPOSAL: Add trade-off considerations as above?
>
>
> 3) Besides the memory impact and rather considering the processing side
> when deriving pairwise keys in Section 2.4.1, providing a longer input
> to HDKF(.) should still be fine. In fact, the whole "authentication
> credentials" are used to build the IKM parameter of HKDF, which in turn
> is used in the Extract step consisting of a single HMAC-Hash()
> invocation, see RFC 5869.
>
>
>      PROPOSAL: if the above is clear and agreed, no action.
> <==
>
>> 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?
> ==>MT
> No, that was just a too compressed way to indicate that a public key can
> be either a signature public key or a Diffie-Hellman public key.
>
> The former case is the typical one, where the group uses the group mode,
> possibly together with the pairwise mode. Then, public keys are
> signature keys.
>
> The latter case is relevant to a group using only the pairwise mode,
> where endpoints will have Diffie-Hellman keys as public keys.
>
>
> PROPOSAL: Considering the possible confusion and the discussion on
> terminology in the previous point, "(signature) public key" can be
> changed to "authentication credential", which is in fact what is used
> when building IKM-Sender and IKM-Recipient through byte concatenation.
> <==
>
>> 3.2
>> See Section 1.1 comment.
> ==>MT
> See reply to Section 1.1 comment above.
>
>
> PROPOSAL: no further action.
> <==
>
>> "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.
> ==>MT
> First off, yes, here "coincide" means "equal". We will replace it (also
> in other parts of the document where it is similarly used).
>
> The first paragraph of Section 3.2 means that: the group has Gid G1
> before rekeying; and, when rekeying the group, the Group Manager
> generates and assigns a new Gid G2 different from G1. That is, two
> consecutively used Gid values are certainly different. Using "equal"
> rather than "coincide" should already make it clearer, and we can also
> explicitly clarify as above.
>
> Besides that and more in general, the Gid G1 may be re-assigned later
> on, at some point in time during the group lifetime. This allows a group
> to "live forever", even after the whole space of Gid values has been
> exhausted, so that values can be reused.
>
> The details really depend on how the Group Manager generates, manages
> and formats the Gid values. An example is provided in Appendix C, where
> a Gid value is composed of a fixed Group Prefix followed by a Group
> Epoch subject to increment at every rekeying. Eventually, the Group
> Epoch would wrap-around, thus yielding the reuse of past Gid values. The
> same can happen with different Gid formats.
>
>
> With the above in mind, let's get to the purpose of doing what is in the
> text you have quoted. The following expands on what is very shortly
> summarized in the draft as: "This ensures that an Observe notification
> [RFC7641] can never
> successfully match against the Observe requests of two different
> observations."
>
>
> In general, as you say, the aim is indeed to keep current members in the
> group, unless to be evicted for other reasons (e.g., as compromised).
> However, a particular "elder member" M as defined in the text is not
> safe to keep in the group, since that would put in danger the security
> of its very old, ongoing observations. In fact, this is what might happen.
>
> * The endpoint M joins the group, obtaining Gid G1 and Sender ID ID1.
> That is, G1 is the "Birth Gid" of M.
>
> * The endpoint M starts an observation OBS1, say using Partial IV equal
> to 42. This observation would leverage an external_aad including the
> triple (42, G1, ID1), in order to match notifications to the observation
> request.
>
> * The group is rekeyed several times, thus changing its Gid value
> multiple times. In the meanwhile, the endpoint M keeps OBS1 active and
> retains its original Sender ID ID1.
>
> * Eventually, the Group Manager rekeys the group and re-assigns Gid G1.
> Now, the newly assigned Gid G1, is equal to the "Birth Gid" of the
> endpoint M.
>
>
> If the endpoint M was not evicted from the group as defined in the
> current draft, the following can happen.
>
> The endpoint M starts a new observation OBS2. As an unlucky coincidence,
> M uses Partial IV equal to 42 in the observation request. Therefore,
> just like the still ongoing OBS1, also OBS2 would leverage an
> external_aad including the triple (42, G1, ID1).
>
> Hence, from then on, a notification related to OBS1 or OBS2 would
> cryptographically match the observation request of both OBS1 and OBS2,
> which is not secure.
>
>
> Instead, by evicting the endpoint M as the "elder member" in question, M
> would eventually re-join the group. When this happens, M terminates all
> its ongoing observations (see Section 6.1), in addition to obtaining a
> new Sender ID and resetting its Sender Sequence Number to use as Partial
> IV to 0 (see Section 2.5.3.1).
>
>
> PROPOSAL: we have not included the above detailed reasoning in the
> draft, since it is more related to design considerations than to
> protocol description. Should we include it instead? If so, would you
> suggest, e.g., Section 3.2 again or rather in the Security
> Considerations section?
> <==
>
>> 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.
> ==>MT
> While the Group Manager knows, e.g, based on the ongoing secure
> communication association it has with that endpoint, the endpoint does
> not "forget" about its membership (except in the case it reboots and
> loses its Security Context).
>
> In general, an endpoint may re-join the group. The details about the
> actual procedure are up to the specific Group Manager (e.g., the one
> defined in draft-ietf-ace-key-groupcomm-oscore), but a re-join can
> happen in a number of cases. For instance:
>
> * Following a forceful eviction. In the situation discussed in the
> previous comment, a re-join would in fact be successful, since the
> eviction was intentionally performed to force a re-joining and the
> termination of very long-living observations.
>
> * As discussed in Section 2.5.3 (and more in details in Section 2.5.3.1
> and 2.5.3.2), an endpoint might need new Security Context parameters
> from the Group Manager. In particular, it requires a new Sender ID if it
> has run out of Sender Sequence Number values, or the latest group keying
> material if it realizes to have missed some group rekeying instances.
>
>      What this draft is concerned about is that the Group Manager is able
> to provide these parameters to the endpoint if need be. Again, how this
> exactly happens depends on the specific Group Manager and the interface
> it provides to the current or candidate group members (see above).
>
>      That said, fully re-joining the group is a minimally granted way to
> acquire all those parameters at once, rather than through more
> fine-grained interactions that the Group Manager might, in general, not
> implement. That is, upon re-joining the group, the endpoint would
> receive a new Sender ID (hence technically becoming a new endpoint) and
> the latest keying material to use in the group.
>
>
> PROPOSAL: if the above is clear and agreed, no action.
> <==
>
>> 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" ?
> ==>MT
> Well, it was not necessarily formerly used, it might have never been before.
>
> That is, assume that possible kid values are {0, 1, ..., 9}.
>
> Under Gid=100, the Group Manager assigns the kid values {0, 1, ..., 7}.
> Then:
>
> * The endpoint with kid = 0 leaves the group.
> * The Group Manager rekeys the group and assigns Gid=200.
>
> Then, under Gid=200:
>
> * The kid values {1, 2, ..., 7} are taken.
> * The kid values {0, 8, 9} are available to be assigned.
>
> Note that 0 was indeed formerly used under the previous Gid value, but 8
> and 9 have never been.
>
>
> PROPOSAL: the text in Figure 2 can be updated as: "After Group ID
> change, an unused kid becomes possible to assign, even if used before
> the Group ID change."
> <==
>
>> 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.
> ==>MT
> Good points. To clarify, a request can be sent over unicast or
> multicast, when protected in group mode or in pairwise mode. That is:
>
> - Multicast request in group mode. This is the typical case for the
> group mode.
>
> - Unicast request in group mode. This is not recommended as discussed in
> Section 11.9.
>
> - Unicast request in pairwise mode. This is the typical case for the
> pairwise mode, and is very similar to how OSCORE works.
>
> - Multicast request in pairwise mode. This is a particular case, with
> two relevant examples:
> --- The last paragraph in Section 9.0, in turn pointing to Section 9.1.
> --- Section 3.4.5 of draft-amsuess-core-cachable-oscore-03
>
> Note that a server might not be able to assert if a received request was
> sent over unicast or multicast. Although for different reasons, this is
> already mentioned in Section 4.4 of RFC 7252, and we had a practical
> evidence in Java implementations.
>
>
> PROPOSAL: based on the above, we can revise the recommendation in
> Section 8 as follows.
>
> i) servers that are not able to distinguish multicast and unicast
> requests are RECOMMENDED to suppress error responses.
>
> ii) servers that are able to distinguish multicast and unicast requests
> are RECOMMENDED to suppress error responses to multicast requests.
>
> <==
>
>> 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.
> ==>MT
> Well, while usually not necessary, it is not wrong to include 'kid
> context' in a response message.
>
> In this particular case, the notification including the new Gid in 'kid
> context' makes the client aware that a group rekeying has happened, or
> is underway and the client has not got rekeying messages yet.
>
> Now, if the client has already switched to the new Security Context,
> then the old one would have been discarded.
>
> If the client has not already switched to the new Security Context, the
> notification can make the client realize to have missed one or more
> group rekeying instances. The client will then promptly check with the
> Group Manager and retrieve the latest group keying material for deriving
> the latest Security Context, rather than doing that anyway (much) later,
> e.g., after experiencing several consecutive decryption failures.
>
> Especially for a client that does not send requests that often (or does
> not receive requests that often if acting also as a server), this hint
> is an opportunistic shortcut to realize its misalignment in terms of
> Security Context, which might otherwise require more time and decryption
> failures.
>
>
> PROPOSAL: if the above is clear and agreed, no action.
> <==
>
>> 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?
> ==>MT
> The section title is "Mandatory-to-Implement Compliance Requirements",
> like in the analogous section of draft-ietf-lake-edhoc , and uses the
> items you mention in a similar way.
>
> If I understand the comment correctly, you would expect a section named
> "Mandatory-to-Implement ..." to cover its points only using MUST/SHALL.
> Correct?
>
>
> PROPOSAL: Since we do mean what is in the text here, it can help to
> change the section title to "Implementation Compliance". Then, some of
> the covered points would be indeed mandatory-to-implement requirements,
> while other would not.
> <==
>
>> 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?
> ==>MT
> There are no differences compared to OSCORE, hence Group OSCORE simply
> inherits what is defined in RFC 8613.
>
> Like in OSCORE, the Master Salt has variable length, and its length and
> value may be preserved or changed when rekeying the group.
>
> Its use and usefulness are also the same as in OSCORE. That is, by
> contributing in the key derivation process, it prevents cryptanalysis
> (see Section 12.6 of RFC 8613 also inherited in Section 11.15 of Group
> OSCORE).
>
>
> PROPOSAL: if the above is clear and agreed, no action.
> <==
>
>> 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  ;)
> ==>MT
> Thanks, I think it is good to elaborate on this.
>
> I am just not sure where exactly. This might require a new dedicated
> subsection within Section 11, together with an effective reminder of
> Section 2.5.1.1 for the reader.
>
>
> PROPOSAL: elaborate on this point, once understood where exactly, but
> most likely within the security considerations.
> <==
>
>> 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.
> ==>MT
> Just like you said: not "owned" as related to a property, but rather to
> something available in local storage.
>
>
> PROPOSAL: change "own"/"owned" to "store"/"stored". This probably
> affects  some other sentence in the document.
> <==
>
>> 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.)
> ==>MT
> Starting from the paragraph "If the countersignature did not cover ..."
> , the text discusses the hypothetical case of the countersignature *not*
> covering the OSCORE option.
>
> To make it clearer and ensure that the reader does not loose context, we
> can perform the following editorial fixes, by also leveraging a bullet
> list and its indentation.
>
> "
> If, hypothetically, the countersignature did not cover the OSCORE option:
>
> * The attack described in Section 11.7.1 would still be possible against
> response messages ...
>
> * A simplification would also be possible in performing the attack,
> since Z is able to ...
>
>      Since the Partial IV is 5 bytes in size, ...
>
>      Note that, by changing the Partial IV ...
> "
>
>
> PROPOSAL: perform the editorial updates above.
> <==
>
>> References
>> Quite a number of references are informative. This may need to be changed for some, based on the guidelines in https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fnormative-informative-references%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0eecb7e9dbee4185f72e08da01b53e35%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637824175785606740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TTBHEGuWiwnKtx8lah0jH%2BtL3MvAbC%2FOfhOosJxgiOU%3D&amp;reserved=0.
> ==>MT
> Thanks, especially two points should be considered from the guidelines
> (restated here for reference in the following comments).
>
> GL1: "Normative references specify documents that must be read to
> understand or implement the technology in the new RFC, or whose
> technology must be present for the technology in the new RFC to work."
>
> GL2: "Even references that are relevant only for optional features must
> be classified as normative if they meet the above conditions for
> normative 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.)
> ==>MT
> For information, note that Section 1 of
> [I-D.mattsson-cfrg-det-sigs-with-noise] says:
>
> “Produced signatures remain fully compatible with unmodified ECDSA and
> EdDSA verifiers and existing key pairs can continue to be used.”
>
> That is, the approach can be used with only one communication side
> supporting it.
>
> Regardless, while keeping the reference as informative, possible
> alternatives to take in Section 10 for addressing the guideline GL1 can be:
>
> * Changing "RECOMMENDED" to "recommended".
>
> * Rephrasing the whole bullet point as follows, or similar:
>
> OLD:
> If elliptic curve signatures are used, it is RECOMMENDED to implement
> deterministic signatures with additional randomness as specified in
> [I-D.mattsson-cfrg-det-sigs-with-noise].
>
> NEW:
> “If elliptic curve signatures are used, it is RECOMMENDED for
> deployments where side-channel and fault injection attacks are a concern
> to implement deterministic signatures with additional randomness, for
> example by using the constructions specified in
> [I-D.mattsson-cfrg-det-sigs-with-noise].”
>
>
> PROPOSAL: keep the reference informative and take one of the two
> alternatives above (preferably the second one).
> <==
>
>> Similar for [I-D.ietf-ace-key-groupcomm-oscore],    [I-D.ietf-ace-key-groupcomm-oscore]: used in a SHOULD.
> ==>MT
> The occurrences in question are:
>
> * Section 3 "The Group Manager": It is RECOMMENDED to use a Group
> Manager as described in [I-D.ietf-ace-key-groupcomm-oscore].
>
> * Section 3.2 "Management of Group Keying Material": The specific group
> key management scheme used to distribute new keying material, is out of
> the scope of this document. However, it is RECOMMENDED that the Group
> Manager supports the Group Rekeying Process described in
> [I-D.ietf-ace-key-groupcomm-oscore].
>
> * Appendix D "Set-up of New Endpoints": It is RECOMMENDED that the join
> process adopts the approach described in
> [I-D.ietf-ace-key-groupcomm-oscore] ...
>
>
> There are two safe alternative to take in the sections above to address
> the guideline GL1:
>
> * Make the reference normative.
>
> * Relax the statements to be non normative, while pointing to the ACE
> document providing a possible Group Manager to use, as including also a
> group rekeying process and a join process in its specification.
>
>
> PROPOSAL: take one of the two alternatives above (preferably the second one)
> <==
>
>> 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.
> ==>MT
> Agree, as consistent with the guideline GL2.
>
>
> PROPOSAL: make RFC 7641 a normative reference.
> <==
>
>> 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.
> ==>MT
> tldr; Consistently with the guideline in GL2, agree that
> echo-request-tag should be a normative reference due to Section 2.5.1.2.
>
> Originally, Appendix E was intended to provide a possible way to deal
> with message freshness and client aliveness, as the analogous of
> Appendix B.1.2 of RFC 8613.
>
> Thus, consistently with RFC 8613, we: i) wrote it as an appendix
> presenting a possible approach to use for synchronization; ii) had
> echo-request-tag as an informative reference; iii) had not normative
> language about it in Sections 6.3 "Message Freshness", 11.13 "Message
> Freshness" and 11.14 "Client Aliveness".
>
> Section 2.5.1.2 and the problem it discusses came later, and admittedly
> raise the bar about the role and importance of echo-request-tag, which
> is still presented as one of two alternatives, but also as the
> RECOMMENDED one.
>
> Thus, it sounds right to make echo-request-tag a normative reference.
>
>
> PROPOSAL: make draft-ietf-core-echo-request-tag a normative reference.
> <==
>
>> 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?
> ==>MT
> This is the case for Appendix D and Appendix E.
>
> As to Appendix D "Set-up of New Endpoints", it uses RECOMMENDED once,
> for draft-ietf-ace-key-groupcomm-oscore regarding the join process to
> use. However, this is simply restating the same normative recommendation
> from Section 3. It should help to simply change "RECOMMENDED" to
> "recommended" in Appendix D. However, based on a previous comment, this
> recommendation throughout the document can be relaxed to be
> non-normative in the first place.
>
> As to Appendix E "Challenge-Response Synchronization", the analogous
> Appendix B.1.2 of RFC 8613 also uses normative language (just like its
> Appendix B.2). That is, once clarified upfront that the appendix
> describes a possible approach, it should be fine to use normative
> language to describe details about how that approach has to work when
> used. However, based on the final comment below, Appendix E might become
> an actual section in the document body.
>
>
> PROPOSAL: in Appendix D, change "RECOMMENDED" to "recommended"
> (regardless of how the recommendation becomes in the rest of the document).
> <==
>
>> 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.
> ==>MT
> Correct, it is indeed determined by the Group Manager; to be clarified
> as, e.g.: "all members of a security group must use a same ciphersuite
> to ...".
>
>
> PROPOSAL: clarify the quoted sentence.
> <==
>
>> 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?
> ==>MT
> The latter.
>
>
> PROPOSAL: no action.
> <==
>
>> 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.
> ==>MT
> Thanks for the suggestion.
>
>
> PROPOSAL: rephrase as per Section 3.
> <==
>
>> 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?
> ==>MT
> See the history of Appendix E in the reply to a previous comment.
>
> As also mentioned above, due to the role/importance of echo-request-tag
> in the more recent Section 2.5.1.2, it would be good to make it a
> section in the document body, e.g., after the current Section 9 "Message
> Processing in Pairwise Mode".
>
> Consistently, and as discussed in a comment above, echo-request-tag
> would also become a normative reference.
>
>
> PROPOSAL: if agreed, move Appendix E to the document body.
> <==
>
>
> ==>MT
> Thanks a lot again!
> <==
>
>>
>> -----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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-oscore-groupcomm-13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0eecb7e9dbee4185f72e08da01b53e35%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637824175785606740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vRCzn%2BhvoalBSOHFSCMZPFNkLzDr%2FZPRQX5uXg179AQ%3D&amp;reserved=0
>>
>> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Foscore-groupcomm&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C0eecb7e9dbee4185f72e08da01b53e35%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637824175785606740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BdCjFis8pnK2wtJzUoiCcOF2CfqUxeIf9g3ybHbCUJM%3D&amp;reserved=0
>>
>> 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!

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)