Adding in edits from Chloe Martindale

[kevinlewi]

General:

It is clear that the authors have taken the previous comments on board and have made many positive changes. However, some important points from previous discussions remain:

-OPAQUE differs in some fundamental ways from PAKEs, for example, it is not PKI-free in the sense of other PAKEs. It would be good to make this very clear in an introductory section where you outline all the properties of standard PAKEs that are different from OPAQUE, and motivate your choices in each case. This is also very important in the security proof: It is different from the case you cite, and consideration needs to be taken here.

-In my opinion, the effort to make the protocol (and its explanation) as general as possible is harming the potential for safe adoption. It is great that there are three recommended configurations on p38, but no details are given on why these have been chosen: Performance? Trusted security? A trade-off? Or specific applications?
I would reorder the whole draft focussing on each specific instantiation in turn, and end with a generalization for potential future (e.g. post-qauntum) applications. This would encourage and allow for careful scrutiny of the cryptographic security of each configuration to be recommended for adoption. (I will not insist on this, as this is a big change, but I would like to see more discussion of the chosen instantiations).

Section 1, paragraph 3:

-Not PKI-free - you say in the previous paragraph that PKI is only used during client registration. Be more precise here: I also am not convinced of the lack of PKI in the rest of the protocol as the term PKI(-free) is not mathematically defined.
-"pre-computation attack" needs defining

Section 6.4.1

In light of comments in https://eprint.iacr.org/2021/839.pdf on the necessity of Hash-to-Curve, maybe highlight here that ECDH is RECOMMENDED where you link forward to your suggested instantiations.

Appendix C.1

You should add public key validation to the HMQV instantiation. Perhaps you tried to avoid the problem of small subgroup attacks by specify a prime order group, but if you have a prime order elliptic curve group that doesn't rule out small subgroup twist attacks. It would be cleaner to just add the public key validation, that way you ensure you have covered all cases in any instantiation.