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
