Subject: [secdir] Secdir last call review of draft-ietf-mmusic-sdp-uks-05

From: Russ Housley via Datatracker <[email-masked]>
Date: Sat, 08 Jun 2019 13:29:05 -0700

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

---

From: Adam Roach <[email-masked]>
Date: Sat, 8 Jun 2019 20:15:34 -0500

> if flaws are found in SHA-256.

Addressing just this point, as I think it was an oversight. Section 3.2 
contains the text:

>    Note:  Should SHA-256 prove to be inadequate at some point in the
>       future (see [AGILITY]), a new TLS extension can be defined that
>       uses a different hash function.

/a

---

From: Adam Roach <[email-masked]>
Date: Sat, 8 Jun 2019 20:24:14 -0500

> If a normative reference for SHA-256 is needed, please cite FIPS 180.

Russ -- can you explain this suggestion further? RFC 6234 has been in 
the downref registry [1] since 2013, and is frequently referenced 
normatively by Standards-Track RFCs. Is there something special about 
the UKS document that makes this common practice inappropriate for it? 
To be clear, I specifically considered this reference when processing 
the UKS document, and believe the second paragraph of section 3 of RFC 
3967 to be applicable.

/a

____
[1] https://datatracker.ietf.org/doc/downref/

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 11 Jun 2019 13:59:31 +1000

Thanks Russ!

I've staged changes based on your review.  You can see those here: 
https://github.com/martinthomson/sdp-uks/pull/10

> failure.  Please add text in Section 2, Section 3.1, and Section 4.1

Thanks for catching this.  It's definitely an important point.

I've added this to S2, and added shorter statements to the other sections.

An unknown key-share attack does not result in the attacker having access to any
confidential information exchanged between victims.  However, the failure in
mutual authentication can enable other attacks.  A victim might send information
to the wrong entity as a result.  Where information is interpreted in context,
misrepresenting that context could lead to the information being misinterpreted.
 
> if flaws are found in SHA-256.

As Adam observed, this is mentioned specifically.  We discussed this point at some length and the document lists the "new extension" path as a way of addressing the need for agility.

> updates RFC 8122, but the Abstract does not mention this.  Please add

Done.

> If a normative reference for SHA-256 is needed, please cite FIPS 180.

Adam covered this, I think.  I don't know what the rules are here and will be guided by others.