Here is my review update for draft-ietf-rtgwg-net2cloud-problem-statement-37:
I will update my review in the datatracker. original comments (in black), updates (in blue) 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." done. 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) The expired draft has been replaced with another draft. The security of the methods would have to be reviewed. Please list that in Section 7. 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). This is just a note to the WG - no action required as long as the WG agrees. 4. Section 5.2, para 2: nit: Please spell out SRH and VxLAN. done. 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." done with a nit: There are two sentences which are basically repeats of each other, they should be streamlined into a single sentence. If it doesn't get edited out, the remaining 'group key encryption' phrase should be changed to 'group key management'. 6. Section 7, last bullet: Change 'improved IPsec tunnel management' to 'scaling IPsec tunnel management' to match the heading for Section 5.1. done 7. Note: there are at least 3 expired drafts referenced as informational by this draft (1 of them is suggested as security improvements). It looks unusual to my eye. Again, either the WG or the IESG should weigh in. Again, just a note to the working group: The expired draft referenced as a security improvement has been replaced with a different draft. Other expired drafts and personal drafts still remain. On Tue, Mar 5, 2024 at 6:19 AM Deb Cooley <[email protected]> wrote: > These are fine resolutions. I'll check the draft once the publication > window opens again. > > Deb > > On Mon, Mar 4, 2024 at 8:05 PM Linda Dunbar <[email protected]> > wrote: > >> 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 <[email protected]> >> Sent: Friday, March 1, 2024 6:13 AM >> To: [email protected] >> Cc: [email protected]; >> [email protected] >> 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. >> >> >> >> >> >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
