Last Call Review of draft-ietf-rum-rue-09
review-ietf-rum-rue-09-secdir-lc-mundy-2021-11-11-00
Request | Review of | draft-ietf-rum-rue |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | IETF Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2021-10-26 | |
Requested | 2021-10-12 | |
Authors | Brian Rosen | |
I-D last updated | 2022-06-09 (Latest revision 2022-02-17) | |
Completed reviews |
Artart IETF Last Call review of -09
by Rich Salz
(diff)
Genart IETF Last Call review of -09 by Matt Joras (diff) Secdir IETF Last Call review of -09 by Russ Mundy (diff) Tsvart Telechat review of -09 by Dr. Bernard D. Aboba (diff) |
|
Assignment | Reviewer | Russ Mundy |
State | Completed | |
Request | IETF Last Call review on draft-ietf-rum-rue by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/FrN072PNvrBGf9Ns29uatO8a7N4 | |
Reviewed revision | 09 (document currently at 11) | |
Result | Has issues | |
Completed | 2021-11-10 |
review-ietf-rum-rue-09-secdir-lc-mundy-2021-11-11-00
Reviewer: Russ Mundy Review result: Almost Ready 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. The Interoperability Profile for Relay User Equipment (draft-ietf-rum-rue-09) document is well structured and written as well as providing very understandable information about the Video Relay Service (VRS) and the Relay User Equipment (RUE). Although I have very limited exposure to this technology area, the functional aspects of this profile seem well thought out and described in the draft. As an Interoperability Profile, I don't find it surprising that there is absence of specific (or even general) security requirements in the current draft. However, this may result in interoperability challenges because RUE and VRS make different choices with respect to the (50+) normative references particularly with respect to security implementations. For example, RFC 7575 defines an "opportunistic security" scenario that might (or might not) be appropriate for some of the RUE activities perhaps anonymous calls as described in 5.2.1. Also, it might (or might not) be acceptable for implementations to negotiate the use of earlier versions of TLS or cryptographic algorithms for some (or none) of the capabilities defined in sections 5 through 10 of the draft. These sections (5 - 10) describe a sufficiently different set of functions that it seems as though some of them might have different security requirements but no specifics security requirements (besides the use of TLS and HTTPS), it would be useful to state the security requirements for each of the sub sections. Although I think that it would be useful to include other security details, identifying at least the basic security requirements that must be provided for each of the defined sub-sections in sections 5 -10 of the draft seems essential. I.e., does each one of the functions require Authentication, Confidentiality and Integrity as defined in section 1 of RFC 8446 (or another RFC) or do some of the defined capabilities only require a subset of these security services? Or do some of the defined functions need something different? Identifying the specific security services required for each of the defined sub-sections would provide more useful information for implementors and deployers who will depend on this specification as well as more consistent security properties in the deployments. Regards, Russ