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

[Deb Cooley <[e-mail]>]

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 <[e-mail]>
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 <[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.
>
>
>
>
>