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

Reply via email to