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

From: Esko Dijk <[email-masked]>
Date: Wed, 12 Jan 2022 08:14:28 +0000

Hi,

This mail is part 2 of my review including the editorial/textual/nit comments.

Best regards
Esko

---

2
"for executing the Group OSCORE protocol (see Section 1.1). "
-> the reference probably needs updating; section 1 defines and explains Group OSCORE security protocol way more than section 1.1 does. 

2.4.1
"Sender Pub Key" and "Recipient Pub Key" items are not defined in the bullet list.

Is "Sender Pub Key" and "Sender Key" the same key? If so, should we give it the same name? If not, they need to be separately defined.
Same question for "Recipient Pub Key" and "Recipient Key".

2.5.3.2. 
Grammar nit: "it resets to 0 ....." -> "it resets .....  to 0"

3
"compiled together" -> "compiled"   (I think the verb already indicates multiple elements are being taken together)

3.2
Following sentence is somewhat unclear; maybe split into 2 sentences, one with the normative requirement and another detailing the cases for leaving the group.

	The Group Manager MUST rekey the group when one or more currently
	   present endpoints leave the group, or in order to evict them as
	   compromised or suspected so. 
E.g.:
	The Group Manager MUST rekey the group when one or more endpoints leave the group. An endpoint may leave the group at own initiative, 
	or may be evicted from the group by the Group Manager e.g. in case an endpoint is compromised, or is suspected to be compromised. 

Grammar nit: "MUST increment by 1 the ...." -> "MUST increment the ....  by 1"

6.2 
There appears to be some minor duplication of description with 6.3. (Although the wording differs.) But not a big issue.

8
Grammar nit: "perform possible retransmissions" -> "perform potential retransmissions"
"in non-multicast environments" -> is "non-multicast transports" meant here? E.g. "Confirmable group requests are acknowledged when sent over non-multicast transports" .

9.3
grammar nit "what defined in Section 8.1.1 of this document holds." -> "what is defined"

9.6
similar "is supported, what defined in" -> "what is defined in "

11.1
Nit "the use of encryption ..." -> "the use of an encryption ..."

11.4 
"large-scale groups" -> why not just "large groups". Appendix E also uses "large groups".

11.5
"large scale groups" -> "large groups"?

Appendix B
"fault tolerance multicast algorithm" -> "fault-tolerant multicast algorithm"

-----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://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-13

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

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

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

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

Ciao!
-- 
Jaime Jiménez

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

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 12 Jan 2022 12:15:12 +0100

Hi Esko,

Thanks a lot for your review and comments!

I've just addressed the editorial points from this mail (see the commit 
at [1]), and will soon start processing your first mail as well.

Please, see below my detailed replies.

Best,
/Marco

[1] 
https://github.com/core-wg/oscore-groupcomm/commit/5b489dcdd4733ae8251cd92ec79a4969cece85bc

On 2022-01-12 09:14, Esko Dijk wrote:
> "for executing the Group OSCORE protocol (see Section 1.1)."

==>MT
The reference was in fact intended to Section 1.1 "Terminology", as 
related to the use of the word "group". The exact spot where the 
reference is included probably created confusion.

I have rephrased as follows:

"As per the terminology in Section 1.1, this document refers to a group 
as a set of endpoints sharing keying material and security parameters 
for executing the Group OSCORE protocol."
<==

> Same question for "Recipient Pub Key" and "Recipient Key".

==>MT
Good point. "Sender Pub Key" and "Sender Key" are definitely not the 
same key (and the same holds for "Recipient Pub Key" and "Recipient Key").

"Sender Key" and "Recipient Key" are inherited from OSCORE (RFC 8613) 
and thus are not re-defined in Section 2.

I have made the following fixes:

* s/other endpoint in the group/other endpoint X in the group

* In the bullet point about IKM-Sender Recipient, s/derivation of the 
Recipient Sender Key/derivation of the Pairwise Recipient Key

... and revised and reordered the following bullet points as below. 
These fit between the bullet points "The Recipient Key ..." and "info 
and L ..."

* The Sender Pub Key is the endpoint's own (signature) public key from 
the Sender Context.

* The Recipient Pub Key is the endpoint X's (signature) public key from 
the Recipient Context associated to the endpoint X.

* The Shared Secret is computed as a cofactor Diffie-Hellman shared 
secret, see Section 5.7.1.2 of [NIST-800-56A], using the Pairwise Key 
Agreement Algorithm. The endpoint uses its private key from the Sender 
Context and the Recipient Pub Key. Note the requirement of validation of 
public keys in Section 11.15. For X25519 and X448, the procedure is 
described in Section 5 of [RFC7748] using public keys mapped to 
Montgomery coordinates, see Section 2.4.2.

* IKM-Sender is the Input Keying Material (IKM) used in the HKDF for the 
derivation of the Pairwise Sender Key. IKM-Sender is the byte string 
concatenation of the Sender Pub Key, the Recipient Pub Key, and the 
Shared Secret. The Sender Pub Key and the Recipient Pub Key are binary 
encoded as defined in Section 2.3.

* IKM-Recipient is the Input Keying Material (IKM) used in the HKDF for 
the derivation of the Pairwise Recipient Key. IKM-Recipient is the byte 
string concatenation of the Recipient Pub Key, the Sender Pub Key, and 
the Shared Secret. The Recipient Pub Key and the Sender Pub Key are 
binary encoded as defined in Section 2.3.

<==

> Grammar nit: "it resets to 0 ....." -> "it resets .....  to 0"

==>MT
Fixed. Now it reads:

"It resets its Sender Sequence Number in its Sender Context to 0."
<==

> "compiled together" -> "compiled"   (I think the verb already indicates multiple elements are being taken together)

==>MT
Rephrased as:

The list of responsibilities of the Group Manager is compiled in Section 
3.3.
<==

> 	or may be evicted from the group by the Group Manager e.g. in case an endpoint is compromised, or is suspected to be compromised.

==>MT
Thanks, now rephrased as you proposed.
<==

> Grammar nit: "MUST increment by 1 the ...." -> "MUST increment the ....  by 1"

==>MT
Rephrased as:

"MUST increment the Key Generation Number for the group by 1."
<==

> There appears to be some minor duplication of description with 6.3. (Although the wording differs.) But not a big issue.

==>MT
Ok.
<==

> Grammar nit: "perform possible retransmissions" -> "perform potential retransmissions"

==>MT
Fixed.
<==

> "in non-multicast environments" -> is "non-multicast transports" meant here? E.g. "Confirmable group requests are acknowledged when sent over non-multicast transports" .

==>MT
Yes, I've rephrased based on your suggestion.
<==

> grammar nit "what defined in Section 8.1.1 of this document holds." -> "what is defined"

==>MT
Fixed.
<==

> similar "is supported, what defined in" -> "what is defined in "

==>MT
Fixed (and same in Sections 9.4 and 9.5).
<==

> "fault tolerance multicast algorithm" -> "fault-tolerant multicast algorithm"

==>MT
Fixed all the above points.
<==

> 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%7C5f8c35d709ab443ccbfd08d9d5a397b9%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637775721604150420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2FzRyxsnZwzBCWKjjECQr6ltDF0XKfUJUQ22w7EYy%2B4k%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%7C5f8c35d709ab443ccbfd08d9d5a397b9%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637775721604150420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=VeUVXIqPQX5LzHBLWkQ3n7q7%2Bv4mVWPO%2FCR7%2FP8hloQ%3D&amp;reserved=0
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
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)