Last Call Review of draft-ietf-mmusic-sdp-mux-attributes-13
review-ietf-mmusic-sdp-mux-attributes-13-secdir-lc-lonvick-2016-07-28-00
| Request | Review of | draft-ietf-mmusic-sdp-mux-attributes |
|---|---|---|
| Requested revision | No specific revision (document currently at 19) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-08-10 | |
| Requested | 2016-07-14 | |
| Authors | Suhas Nandakumar | |
| Draft last updated | 2016-07-28 | |
| Completed reviews |
Genart Last Call review of -13
by
Dan Romascanu
(diff)
Secdir Last Call review of -13 by Chris M. Lonvick (diff) |
|
| Assignment | Reviewer | Chris M. Lonvick |
| State | Completed | |
| Review |
review-ietf-mmusic-sdp-mux-attributes-13-secdir-lc-lonvick-2016-07-28
|
|
| Reviewed revision | 13 (document currently at 19) | |
| Result | Has Issues | |
| Completed | 2016-07-28 |
review-ietf-mmusic-sdp-mux-attributes-13-secdir-lc-lonvick-2016-07-28-00
Apologies for the duplication - resending to the right alias.
On 7/24/16 9:39 AM, Chris Lonvick
wrote:
Hi,
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.
I've been rather busy and haven't had time to thoroughly review
this document. But I did look at the Security Considerations
section and will recommend that some additions be made. The
Security Considerations section says, "This document does not add
any new security considerations beyond the existing considerations
in the RFCs for protocols that are being multiplexed together. "
(First paragraph.) I believe that it would be helpful to readers
and implementers if the specification were to give pointers to
RFCs for protocols that are being multiplexed together, and their
security considerations.
The section continues by saying, "The ways that SRTP streams are
keyed is not believed to create any two-time pad vulnerability for
the currently defined SRTP keying mechanism." (Second paragraph.)
I may not have seen it but I don't believe that this document
specifies keying for SRTP streams, but only references RFC4567
(Section 5.35) and
RFC4572 (Section 5.36). If that's the case, then this document
doesn't need to opine about possible vulnerabilities in that area;
leave it to those or subsequent documents to make that analysis.
It would be appropriate to reiterate that the CAUTION category may
produce some problems.
For completeness, it may be good to include pointers to other
mmusic and SDP documents that have addressed security aspects. A
statement of how that may apply to this specification would be
appropriate. I don't think this would need to be detailed.
Best regards,
Chris