Last Call Review of draft-ietf-mmusic-sdp-uks-05
review-ietf-mmusic-sdp-uks-05-secdir-lc-housley-2019-06-08-00

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].