RE: Secdir last call review of draft-ietf-rtgwg-net2cloud-problem-statement-36

[Linda Dunbar <[e-mail]>]

Deb,

Thank you very much for the second review and the comments.
The detailed resolutions are inserted below.

Linda

-----Original Message-----
From: Deb Cooley via Datatracker <[e-mail]>
Sent: Friday, March 1, 2024 6:13 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Secdir last call review of draft-ietf-rtgwg-net2cloud-problem-statement-36

Reviewer: Deb Cooley
Review result: Has Issues

Reviewer: Deb Cooley

Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other last call comments.

Document: draft-ietf-rtgwg-net2cloud-problem-statement-36

Reviewer: Deb Cooley

Review Date: 2024-03-01 (sort of last call)

The summary of the review is:

1.  Section 5.1, paragraph 2:  Certainly the principles and assumptions of RFC
4535* would apply to any group key management situation (note the word change from 'group encryption' to 'group key management').  The specific protocol addressed by that RFC isn't being used here (even though they mention ISAKMP).
How about something like this:

"The group key management protocol documented in [RFC4535] outlines the relevant security risks for any group key management system in Section 3 (Security Considerations).  While this particular protocol isn't being suggested, the drawbacks and risks of group key management are still relevant."
[Linda] Thank you very much for the suggested wording. Changed in v-37

2.  Section 5.1, paragraph 3:  The draft referenced here is expired and the security of the methods would have to be reviewed.  (that is listed in Section
7)
[Linda] removed the reference to SECURE-EVPN as the draft authors seem not eager to move the draft forward.

3.  Section 5.2:  The draft referenced in this section is (currently) an individual draft, and again the security of the methods would have to be reviewed. (I see that WG adoption has been requested, and the draft is listed in Section 7).
[Linda] Is it Okay?

4.  Section 5.2, para 2:  nit:  Please spell out SRH and VxLAN.
[Linda] added.


5.  Section 7, second to last bullet:  Please see my comments on Section 5.1.
I would use the words 'group key management' vice 'group encryption'.  It is the key management of a group system that is tricky and problematic, not the actual encryption per se. Something like this perhaps:

"Group key management comes with security risks such as:  keys being used too long, single points of compromise (one compromise affects the whole group), key distribution vulnerabilities, key generation vulnerabilities, to name a few.
[RFC4535] outlines the security risks in Section 3 (Security Considerations).
While this specific protocol isn't being suggested the risks and vulnerabilities apply to any group key management system."
[Linda] Thank you very much for the suggested wording. Changed in v-37.

6.  Section 7, last bullet:  Change 'improved IPsec tunnel management' to 'scaling IPsec tunnel management' to match the heading for Section 5.1.
[Linda] Changed.

7.  Note:  there are at least 3 expired drafts referenced as informational by this draft (1 of them is suggested as a security improvement).  It looks unusual to my eye.  Again, either the WG or the IESG should weigh in.
[Linda] all updated.

 * RFC 4535: Thanks for that blast from the past, it has been decades since  I've seen some of those authors names.