Reviewer: Russ Housley Review result: Has Issues I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-mmusic-sdp-uks-05 Reviewer: Russ Housley Review Date: 2019-06-08 IETF LC End Date: 2019-06-19 IESG Telechat date: unknown Summary: Has Issues Major Concerns: In Section 2 (and other places), explaining the attack, the authors correctly explain that a malicious participant in a protocol claims to control a key that is in reality controlled by some other actor. The confidentiality and access control implications need to be explained. The malicious actor cannot decrypt the traffic. However, victum may release information to the wrong party because of the authentication failure. Please add text in Section 2, Section 3.1, and Section 4.1 on this topic. In Section 3.2, SHA-256 is the only supported hash function. In some manner algorithm agility needs to be provided. This could be done by using the same hash function as TLS is negotiating elsewhere, by including a hash algorithm identifier, or explicitly stating that a new TLS extension will be defined for use with another hash function if flaws are found in SHA-256. Minor Concerns: The title page header and the Introduction indicate that this document updates RFC 8122, but the Abstract does not mention this. Please add this to the Abstract. In Section 3.2, I think that [SHA] should be an informative reference. If a normative reference for SHA-256 is needed, please cite FIPS 180. Nits: Section 3: I suggested rewording: OLD: Both SIP and WebRTC identity providers are not required to perform this validation. This is not an issue because verifying control of the associated keys is not a necessary condition for a secure protocol, nor would it be sufficient to prevent attack [SIGMA]. NEW: Neither SIP nor WebRTC identity providers are required to perform this validation; however, this is not an issue because verifying control of the associated keys is not a necessary condition for a secure protocol, nor would it be sufficient to prevent attack [SIGMA].
