Jonathan: Thanks for the review.
> Here are my comments on the draft. > > 1. Section 4 covers a lot of ground and is difficult to follow. I > suggest it be split into subsections (e.g. "4.1 PSKs Shared with > Multiple Group Members" and "4.2 Weak Entropy PSKs") and move the > attack description to an appendix. I just reread it, and I think that the flow is okay. It is about 2 pages. That said, I can see it dividing into two clean subsections. I'd prefer to leave the attack in the body of the first subsection. > 2. In Section 4, para 2, the reference "As discussed in Section 6" > refers to the use case of provisioning where multiple clients or > servers share the same PSK, but Section 6 covers all use cases (and > also provisioning). I suggest to create a couple more subsections for > clarity and accurate referencing: "6.1 Use Cases for Pair-wise > External PSKs" and "6.2 Use Cases for PSKs Shared with Multiple > Entities", shifting the provisioning sections to 6.3 and 6.4. Then > the Section 4 citation can refer to Section 6.2. I think your only concern is the granularity of the forward reference. I'm not sure most people would be confused. > 3. Section 7, item 4 is missing a word. s/This protects an attacker > from/This protects against an attacker from/ Against the original text: s/protects/prevents/ > 4. Since there is no mitigation against revealing PSK identity, it is > more accurate to rename Section 5 "Privacy Concerns". How about "Privacy Considerations"? > 5. Section 4, para starting with "Finally, in addition to these...": > s/may negatively affects deployments/may negatively affect > deployments/ Agreed. > 6. Section 5, para 1: I don't think "oppress" is the right word to use > here. Perhaps, "suppress" would be better. Agreed. > 7. In Section 6, the last paragraph refers to Section 7 as the final > sentence. I assume this reference is for the recommendation to not > share a PSK between more than one node, but it is not clear. The > previous sentence says do not share PSKs "even if other accommodations > are made", but this conflicts with item 2 of Section 7 which says do > not share PSKs "unless other accommodations are made". How about: The exact provisioning process depends on the system requirements and threat model. Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several node is sometimes unavoidable. When PSK sharing happens, other accommodations as needed as discussed in Section 7. > 8. It is not clear why "client certificate authentication after > PSK-based connection establishment", mentioned at the end of Section > 6, is not a sufficient accommodation. Should it be added to Section > 7, item 2? Agreed, > 9. Section 7.1.2, first para, s/clash/collide That is better. > 10. Section 7.1.2 describes a possible concern regarding PSK identity > collisions, but it does not provide a recommendation/mitigation for > vendors or users. What should the reader do with this information? It means the application, not the stack need to handle the collision by following the advice in the document. > 11. Section 6, item 2: the term "logical nodes" is not defined. I suggest dropping "logical" Russ _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
