Re: [MMUSIC] Secdir last call review of draft-ietf-mmusic-sdp-uks-05

["Martin Thomson" <[e-mail]>]

Thanks Russ!

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

On Sun, Jun 9, 2019, at 06:29, Russ Housley via Datatracker wrote:
> 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.

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

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.

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

Done.

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

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