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

[Marco Tiloca <[e-mail]>]

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=[e-mail]. 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./
>
> Is the first part of the sentence redundant?

==>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/
>
> I wonder if this name could be confused for an algorithm used to 
> encrypt the signature.

==>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/
>
> Could it be ambiguous what the "full set" is?

==>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.
> /
>
> True, but is it important to mention? What to do with this information?

==>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./
>
> Identifier rather than indicator? Not 100% clear what an indicator is 
> in this context.

==>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}})./
>
> Isn't this just like in OSCORE? In the sense that a new context gets a 
> reset fresh replay window.

==>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}})./
>
> Just restating what is said shortly above?

==>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./
>
> Good to say that it is recommended to assign groups to different 
> multicast IPs when possible?

==>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 <[e-mail]> on behalf of Rikard Höglund 
> <rikard.hoglund=[e-mail]>
> *Sent:* Tuesday, January 11, 2022 23:20
> *To:* Jaime Jiménez <[e-mail]>; [e-mail] <[e-mail]>
> *Subject:* Re: [core] 🔔 WG Last Call of draft-ietf-core-oscore-groupcomm
>
> 	
> rikard.hoglund=[e-mail] 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 <[e-mail]> on behalf of Jaime Jiménez 
> <[e-mail]>
> *Sent:* Wednesday, December 1, 2021 16:59
> *To:* [e-mail] <[e-mail]>
> *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%7Cmarco.tiloca%40ri.se%7C0883879e9f3342c1031d08d9fd0fff88%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819068004013517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5sS%2Fu%2B58zddw5LPOVraLom6TVHjVE0rbczCR0ZevvF4%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%7Cmarco.tiloca%40ri.se%7C0883879e9f3342c1031d08d9fd0fff88%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637819068004013517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5BtKKTLA9ZjZaVJkemzoHOhCYc%2Ba85bKYqWub3j2i2U%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
> > [e-mail]
> > 
> 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>
>
> _______________________________________________
> core mailing list
> [e-mail]
> 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>
>
> _______________________________________________
> core mailing list
> [e-mail]
> 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: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)