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.
