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

From: Rikard Höglund <[email-masked]>
Date: Thu, 3 Mar 2022 12:18:26 +0000

Hello.

My apologies for sending this out so late. I have synced with Marco offline so at least he is aware it is coming.

Best wishes
Rikard

Section 2:
Regardless of what it actually supports,
   each endpoint of a group is aware of whether the group uses the group
   mode, or the pairwise mode, or both.

Is the first part of the sentence redundant?

Section 2:
Signature Encryption Algorithm

I wonder if this name could be confused for an algorithm used to encrypt the signature.

Section 2.2:
A newly installed Recipient Context that has required to delete another Recipient Context is initialized with an invalid Replay Window

Is it the case that any Recipient Context created after some have been deleted is to have its Replay Window be invalid?

Section "Authentication Credentials":
The used format MUST provide the public key as well as the full set of information related to the public key algorithm

Could it be ambiguous what the "full set" is?

Section "Authentication Credentials":
Storing whole authentication credentials rather than only a subset of those may result in a non-negligible storage overhead.

May be confusing as the previous paragraph is about only storing a subset of a chain or a bag. It could be clearer that this is an explanation and justification of a design choice.

Section 2.4:
Group OSCORE keys used for both signature and encryption MUST NOT be used for any other purposes than Group OSCORE.

The keys are also used towards the Group Manager, which arguably isn't exactly Group OSCORE, but rather the joining procedure.

Section 2.4.3:
On the other hand, when combining group and pairwise communication modes, this may result in the Partial IV values moving forward more often. This can happen when a client engages in frequent or long sequences of one-to-one exchanges with servers in the group, by sending requests over unicast.

True, but is it important to mention? What to do with this information?

Section "Loss of Mutable Security Context":
An adversary may leverage the above to perform a Denial of Service attack and prevent some group members from communicating altogether. That is, the adversary can first block the communication path between the Group Manager and some individual group members. This can be achieved, for instance, by injecting fake responses to DNS queries for the Group Manager hostname, or by removing a network link used for routing traffic towards the Group Manager. Then, the adversary can trigger a short power outage, which can result in a mass power-cycle and reboot for some endpoints in the group. After that, such endpoints that have lost their Sender Context and/or Recipient Contexts following the reboot would not be able to obtain new Security Context parameters from the Group Manager as specified above. Thus, they would not be able to further communicate in the group until connectivity with the Group Manager is restored.

Is this big section relevant to mention? If an adversary can induce power outages it can do a lot more damage, and in different ways. Perhaps it can be in the security considerations if kept.

Section "Exhaustion of Sender Sequence Number":
Exhaustion of Sender Sequence Number

May be enough with just a reference to the equivalent OSCORE section? And saying to retrieve new Security Context parameters from the GM

Section 2.5.3:
The Recipient ID ('kid') SHOULD NOT be considered as a persistent and reliable indicator of a group member.

Identifier rather than indicator? Not 100% clear what an indicator is in this context.

Section 9.6:
Also, upon the establishment of a new Security Context, the client re-initializes its Replay Windows in its Recipient Contexts (see {{sec-group-key-management}}).

Isn't this just like in OSCORE? In the sense that a new context gets a reset fresh replay window.

Section 9.6:
However, since the notification is protected in pairwise mode, the public key is not used for verifying a countersignature as in {{ssec-verify-response}}. Instead, the expected server's authentication credential - namely Recipient Auth Cred and including the server's public key - was taken as input to derive the Pairwise Recipient Key used to decrypt and verify the notification (see {{key-derivation-pairwise}}).

Just restating what is said shortly above?

Section 11.6:
The entity assigning an IP multicast address may help limiting the chances to experience such collisions of Group Identifiers.

Good to say that it is recommended to assign groups to different multicast IPs when possible?

Section 11.7.1:
Upon receiving M2, there is a probability equal to 2^-64 that Y successfully verifies the same unchanged MAC by using the Pairwise Recipient Key associated with X in G2.

I wonder why the probability is 2^-64, why is this attack better than simply forging a message to a group member (and hoping the MAC verifies)?

________________________________
From: core <[email-masked]> on behalf of Rikard Höglund <rikard.hoglund=[email-masked]>
Sent: Tuesday, January 11, 2022 23:20
To: Jaime Jiménez <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm

rikard.hoglund=[email-masked] liknar någon som tidigare har skickat e-post till dig, men kanske inte är den personen. Se varför det här kan vara en risk<http://aka.ms/LearnAboutSenderIdentification>
Hello.

I am working on a review that I unfortunately have not been able to finish yet. However I will be sending it out before the end of the week.

Best wishes
Rikard Höglund
________________________________
From: core <[email-masked]> on behalf of Jaime Jiménez <[email-masked]>
Sent: Wednesday, December 1, 2021 16:59
To: [email-masked] <[email-masked]>
Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm

Dear all,

the deadline for this WGLC is today. Given that we have not received enough reviews and that the Christmas period is arriving soon, we will have to extend the deadline for this.

Marco and I propose 6 more weeks of extension until 2022-01-11 Tuesday, to give more ample time for thorough reviews.

Ciao!
--
Jaime Jiménez

On Tue, Nov 9, 2021, at 8:59 PM, Jaime Jiménez wrote:
> 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%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6B7dEbJ8l4%2Bvc%2BxrMBiFxN6GRf7lAoi5FUZBI68cdNQ%3D&amp;reserved=0<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-oscore-groupcomm-13&data=04%7C01%7Crikard.hoglund%40ri.se%7C7ba50feff51e434f8a5d08d9d5509c66%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637775365045265830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Rg%2FMVQRClLdQgYQc7LdgXYd9n3ewvf7gPSA1%2Buo%2Fq0Y%3D&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%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WFXtDpiQ1RRiW1hP1JeUx0%2F4%2F5i1UKOia9ZNT5NdIns%3D&amp;reserved=0<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Foscore-groupcomm&data=04%7C01%7Crikard.hoglund%40ri.se%7C7ba50feff51e434f8a5d08d9d5509c66%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637775365045265830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=csqpQ4kSZPHkcJ3CZmy4kUuGrCfwq3mCioLOqVDj7AM%3D&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!
> --
> Jaime Jiménez
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=O4bk%2Fdhhl6idWhXDkqxWNUyGOUgUp4fqVkeU0hYkCDE%3D&amp;reserved=0<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=04%7C01%7Crikard.hoglund%40ri.se%7C7ba50feff51e434f8a5d08d9d5509c66%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637775365045265830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=neDFoYgmVqMjKRSFtOZVLQjSdlzcyZOzQCCiDFtTHL0%3D&reserved=0>

_______________________________________________
core mailing list
[email-masked]
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=O4bk%2Fdhhl6idWhXDkqxWNUyGOUgUp4fqVkeU0hYkCDE%3D&amp;reserved=0<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=04%7C01%7Crikard.hoglund%40ri.se%7C7ba50feff51e434f8a5d08d9d5509c66%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637775365045421867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=nHfCoHjEXZGX16UUXWUCaFdy93iNwNCM8B%2BIUvxQLlM%3D&reserved=0>

---

From: Marco Tiloca <[email-masked]>
Date: Sat, 5 Mar 2022 11:59:18 +0100

Hi Rikard,

Thanks a lot for your review! (and for having considered the latest 
Editor's copy)

Updates based on your comments are captured in the commit at [1].

Please, find also my answers in line.

Best,
/Marco

[1] 
https://github.com/core-wg/oscore-groupcomm/commit/532534ebd3240215b2b6a5e9ac0bdd73ac90d0f9

On 2022-03-03 13:18, Rikard Höglund wrote:
>
> 	
> Vissa som fått det här meddelandet får inte ofta e-post från 
> rikard.hoglund=[email-masked]. Se varför det är viktigt 
> <http://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Hello.
>
> My apologies for sending this out so late. I have synced with Marco 
> offline so at least he is aware it is coming.
>
> Best wishes
> Rikard
>
> *Section 2:*
> /Regardless of what it actually supports,
> /
> /   each endpoint of a group is aware of whether the group uses the group/
> /   mode, or the pairwise mode, or both./
>

==>MT
Rephrased as follows.

"Each endpoint of a group is aware of whether the group uses the group 
mode, or the pairwise mode, or both. Then, an endpoint can use any mode 
it supports if also used in the group."
<==

>
> *Section 2:*
> /Signature Encryption Algorithm/
>

==>MT
To avoid confusion, I've now added the following sentence.

"This algorithm is not used to encrypt the countersignature in messages 
protected using the group mode, for which the method defined in Section 
4.1 is used."
<==

>
> *Section 2.2:*
> /A newly installed Recipient Context that has required to delete 
> another Recipient Context is initialized with an invalid Replay Window/
>
> Is it the case that any Recipient Context created after some have been 
> deleted is to have its Replay Window be invalid?

==>MT
Yes. Now rephrased as below.

"If the new Recipient Context has been installed after the endpoint has 
experienced the overflow above, then the Recipient Context is 
initialized with an invalid Replay Window ..."
<==

>
> *Section "Authentication Credentials":*
> /The used format MUST provide the public key as well as the full set 
> of information related to the public key algorithm/
>

==>MT
Changed to "comprehensive set".
<==

>
> *Section "Authentication Credentials":*
> /Storing whole authentication credentials rather than only a subset of 
> those may result in a non-negligible storage overhead./
>
> May be confusing as the previous paragraph is about only storing a 
> subset of a chain or a bag. It could be clearer that this is an 
> explanation and justification of a design choice.

==>MT
The chain/bag is not a credential. The previous paragraph says that the 
actual credential is only the end-entity certificate provided within the 
chain/bag, and as such it is stored and used later on.
<==

>
> *Section 2.4:*
> /Group OSCORE keys used for both signature and encryption MUST NOT be 
> used for any other purposes than Group OSCORE./
>
> The keys are also used towards the Group Manager, which arguably isn't 
> exactly Group OSCORE, but rather the joining procedure.

==>MT
Rephrased as follows.

"Group OSCORE keys used for both signature and encryption MUST be used 
only for purposes related to Group OSCORE. These include the processing 
of messages with Group OSCORE, as well as performing proof-of-possession 
of private keys, e.g., upon joining a group through the Group Manager 
(see Section 3)."
<==

>
> *Section 2.4.3:*
> /On the other hand, when combining group and pairwise communication 
> modes, this may result in the Partial IV values moving forward more 
> often. This can happen when a client engages in frequent or long 
> sequences of one-to-one exchanges with servers in the group, by 
> sending requests over unicast.
> /
>

==>MT
Added a sentence to clarify practical implications.

"In turn, this contributes to a sooner exhaustion of the Sender Sequence 
Number space of the client, which would then require to take actions for 
deriving a new Sender Context before resuming communications in the 
group (see Section 2.5.2)."
<==

>
> *Section "Loss of Mutable Security Context":*
> /An adversary may leverage the above to perform a Denial of Service 
> attack and prevent some group members from communicating altogether. 
> That is, the adversary can first block the communication path between 
> the Group Manager and some individual group members. This can be 
> achieved, for instance, by injecting fake responses to DNS queries for 
> the Group Manager hostname, or by removing a network link used for 
> routing traffic towards the Group Manager. Then, the adversary can 
> trigger a short power outage, which can result in a mass power-cycle 
> and reboot for some endpoints in the group. After that, such endpoints 
> that have lost their Sender Context and/or Recipient Contexts 
> following the reboot would not be able to obtain new Security Context 
> parameters from the Group Manager as specified above. Thus, they would 
> not be able to further communicate in the group until connectivity 
> with the Group Manager is restored./
>
> Is this big section relevant to mention? If an adversary can induce 
> power outages it can do a lot more damage, and in different ways. 
> Perhaps it can be in the security considerations if kept.

==>MT
This input came from another review and it conveniently fits here, since 
it builds on the exact context from the previous paragraphs in Section 
2.5.1.1 (which would be quite hard to build again later on in the 
security considerations).

I have however made some minor rephrasing as below.

OLD:
"Then, the adversary can trigger a short power outage, which can result 
in a mass power-cycle and reboot for some endpoints in the group."

NEW:
"Then, the adversary can induce a reboot for some endpoints in the 
group, e.g., by triggering a short power outage."
<==

>
> *Section "Exhaustion of Sender Sequence Number":*
> /Exhaustion of Sender Sequence Number/
>
> May be enough with just a reference to the equivalent OSCORE section? 
> And saying to retrieve new Security Context parameters from the GM

==>MT
Kept as is as the result of discussions/reviews on previous versions of 
the document.
<==

>
> *Section 2.5.3:*
> /The Recipient ID ('kid') SHOULD NOT be considered as a persistent and 
> reliable indicator of a group member./
>

==>MT
Changed to "identifier".
<==

>
> *Section 9.6:*
> /Also, upon the establishment of a new Security Context, the client 
> re-initializes its Replay Windows in its Recipient Contexts (see 
> {{sec-group-key-management}})./
>

==>MT
Yes, with the difference that, in general, there are multiple Recipient 
Contexts within the same Security Context.

However, I took the opportunity to fix a section reference, now 
correctly pointing to Section 2.2.
<==

>
> *Section 9.6:*
> /However, since the notification is protected in pairwise mode, the 
> public key is not used for verifying a countersignature as in 
> {{ssec-verify-response}}. Instead, the expected server's 
> authentication credential - namely Recipient Auth Cred and including 
> the server's public key - was taken as input to derive the Pairwise 
> Recipient Key used to decrypt and verify the notification (see 
> {{key-derivation-pairwise}})./
>

==>MT
Replaced the quoted text with the following sentence.

"As to the expected server's authentication credential, the same holds 
as specified above for non-notification responses."
<==

>
> *Section 11.6:*
> /The entity assigning an IP multicast address may help limiting the 
> chances to experience such collisions of Group Identifiers./
>

==>MT
The possible mapping between security groups and CoAP groups is actually 
discussed in the groupcomm-bis document.

This paragraph was meant to suggest a different kind of help. I've now 
rephrased as below, to provide more context.

"In case multiple groups use the same IP multicast address, the entity 
assigning that address may help limiting the chances to experience such 
collisions of Group Identifiers. In particular, it may allow the Group 
Managers of those groups using the same IP multicast address to share 
their respective list of assigned Group Identifiers currently in use."
<==

>
> *Section 11.7.1:*
> /Upon receiving M2, there is a probability equal to 2^-64 that Y 
> successfully verifies the same unchanged MAC by using the Pairwise 
> Recipient Key associated with X in G2./
>
> I wonder why the probability is 2^-64, why is this attack better than 
> simply forging a message to a group member (and hoping the MAC verifies)?

==>MT
(Following some more section restructuring, this is now Section 12.7.1)

If one forges a message from scratch, one has indeed the same 
probability to build something that yields a successful decryption, 
i.e., such that the MAC verifies.

On top of that, here the result would still be the message originally 
sent to G1, created as valid by its sender X.
<==

>
> ------------------------------------------------------------------------
> *From:* core <[email-masked]> on behalf of Rikard Höglund 
> <rikard.hoglund=[email-masked]>
> *Sent:* Tuesday, January 11, 2022 23:20
> *To:* Jaime Jiménez <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm
>
> 	
> rikard.hoglund=[email-masked] liknar någon som tidigare har 
> skickat e-post till dig, men kanske inte är den personen. Se varför 
> det här kan vara en risk <http://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Hello.
>
> I am working on a review that I unfortunately have not been able to 
> finish yet. However I will be sending it out before the end of the week.
>
> Best wishes
> Rikard Höglund
> ------------------------------------------------------------------------
> *From:* core <[email-masked]> on behalf of Jaime Jiménez 
> <[email-masked]>
> *Sent:* Wednesday, December 1, 2021 16:59
> *To:* [email-masked] <[email-masked]>
> *Subject:* Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm
> Dear all,
>
> the deadline for this WGLC is today. Given that we have not received 
> enough reviews and that the Christmas period is arriving soon, we will 
> have to extend the deadline for this.
>
> Marco and I propose 6 more weeks of extension until 2022-01-11 
> Tuesday, to give more ample time for thorough reviews.
>
> Ciao!
> -- 
> Jaime Jiménez
>
> 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%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6B7dEbJ8l4%2Bvc%2BxrMBiFxN6GRf7lAoi5FUZBI68cdNQ%3D&amp;reserved=0 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-oscore-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C0883879e9f3342c1031d08d9fd0fff88%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819068004013517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5sS%2Fu%2B58zddw5LPOVraLom6TVHjVE0rbczCR0ZevvF4%3D&reserved=0>
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Foscore-groupcomm&amp;data=04%7C01%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WFXtDpiQ1RRiW1hP1JeUx0%2F4%2F5i1UKOia9ZNT5NdIns%3D&amp;reserved=0 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Foscore-groupcomm&data=04%7C01%7Cmarco.tiloca%40ri.se%7C0883879e9f3342c1031d08d9fd0fff88%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819068004013517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5BtKKTLA9ZjZaVJkemzoHOhCYc%2Ba85bKYqWub3j2i2U%3D&reserved=0>
> >
> >>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
> >
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=O4bk%2Fdhhl6idWhXDkqxWNUyGOUgUp4fqVkeU0hYkCDE%3D&amp;reserved=0 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=04%7C01%7Cmarco.tiloca%40ri.se%7C0883879e9f3342c1031d08d9fd0fff88%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819068004013517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ag4Y%2BR1j7LSF4Vaua0XVGI7WP%2FYSXIzoXAd0rlAl5uA%3D&reserved=0>
>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Crikard.hoglund%40ri.se%7Cc5146db032204faf125d08d9b4e3a676%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637739712988375219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=O4bk%2Fdhhl6idWhXDkqxWNUyGOUgUp4fqVkeU0hYkCDE%3D&amp;reserved=0 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=04%7C01%7Cmarco.tiloca%40ri.se%7C0883879e9f3342c1031d08d9fd0fff88%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819068004013517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ag4Y%2BR1j7LSF4Vaua0XVGI7WP%2FYSXIzoXAd0rlAl5uA%3D&reserved=0>
>
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

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

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Esko Dijk <[email-masked]>
Date: Wed, 9 Mar 2022 10:11:52 +0000

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.

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.

Best regards
Esko

-----Original Message-----
From: Marco Tiloca <[email-masked]> 
Sent: Wednesday, January 19, 2022 12:06
To: Esko Dijk <[email-masked]>; Jaime Jiménez <[email-masked]>; [email-masked]
Cc: [email-masked]
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%7C0d8f108545ce472d32cc08d9d4e2ce2b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637774893728988984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=hUDgSQ3DeCr5gC0aQmHfwn2ILs7uL8lD2rhAXbggads%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 <[email-masked]> On Behalf Of Jaime Jiménez
> Sent: Tuesday, November 9, 2021 20:00
> To: [email-masked]
> Cc: [email-masked]
> 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%7C0d8f108545ce472d32cc08d9d4e2ce2b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637774893728988984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=VVud%2BqJGlRNfTaOAEL%2FDTpSAd9aqrkCRJCipL7OnybM%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%7C0d8f108545ce472d32cc08d9d4e2ce2b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637774893728988984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=rlZjqNw14TCBifx4PNLbJcFnBl5bsjIv%2F%2FYUKo1RJ%2B0%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.
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 9 Mar 2022 16:49:19 +0100

Hi Esko,

> 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!
<==

==>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

<==

>> 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
>> 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
>>
>> 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
>>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Esko Dijk <[email-masked]>
Date: Thu, 17 Mar 2022 13:29:56 +0000

Thanks Marco,

Yes Section 3.2.1.1 looks good now and is in line with my comment of dealing with this in a separate section.

Regards
Esko

-----Original Message-----
From: Marco Tiloca <[email-masked]> 
Sent: Wednesday, March 9, 2022 16:49
To: Esko Dijk <[email-masked]>; Jaime Jiménez <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm

Hi Esko,

==>MT

==>MT

Best,
/Marco

[1] 

<==

-- 
Marco Tiloca
Ph.D., Senior Researcher