Incorporating Julia Hesse's edits

[kevinlewi]

Editorial:

• Sec 2.1, DeriveKeyPair: maybe assign names to the output of this API?
  It is also unclear what happens with the public key. Is that needed
  anywhere else?

Changed the DeriveKeyPair definition to read:

• DeriveKeyPair(seed, info): Create and output (sk, pk), consisting of a private and public key derived deterministically from a seed`` and info`` parameter, as described in {{OPRF, Section 3.2}}.

The public key is not used in one case (when we compute (oprf_key, _) = DeriveKeyPair(seed, "OPAQUE-DeriveKeyPair")), but it is used for some configurations in the AKE section (for example in 3DH ristretto255: DeriveDiffieHellmanKeyPair(seed): This function is implemented as DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is as specified in {{OPRF, Section 3.2}}. The public value from DeriveKeyPair is encoded using SerializeElement from {{Section 2.1 of OPRF}}.)
 - Sec 3.1, "The server can use this single pair of keys with multiple
clients and can opt to use multiple seeds (so long as they are kept
consistent for each client)." - WhatsApp's usage of OPAQUE is one
example where reusing a key among several clients is devastating for
the security of the overall scheme. It should be made super clear in
this draft that individual keys have to be used per client. There are
other parts in the draft where this is actually taken care of, but the
cited paragraph here is too ambiguous, imo. What is a "client"? And is
it really okay to use the same key and same seed for many clients?

I think there might be some confusion here. The sentence, "The server can use this single pair of keys with multiple clients" refers to the server_private_key and server_public_key parameters used in the AKE section, not the OPRF key. The "oprf_seed" is something we believe can be re-used for each client, but anyway the sentence says it is OK to use multiple seeds if desired. The actual OPRF key is not referenced in this paragraph, because it is anyway derived from KDF(oprf_seed, credential_identifier), and not handpicked by the server.
To address the confusion, I changed the text to say, "The server can use server_private_key and server_public_key with multiple clients and can opt to use multiple seeds (so long as they are kept consistent for each client)." (instead of saying "this single pair of keys", just spelling out which pair of keys the text is referring to).

 - I had a hard time following the modularization of the protocol. In
Section 3, the phases are described as Setup, Offline registration, and
online AKE. That is decoupled from 4, which describes client credential
storage and key recovery. This touches both offline registration and
online AKE phases. I do not want to suggest to do any large changes, but
2-3 clarifying sentences about the structure of the
sections/explanations of the different protocol phases could be added.

I believe this is already addressed by the paragraph at the end of Section 3, "The rest of this document describes the details of these stages in detail. Section 4 describes how client credential information is generated, encoded, and stored on the server during registration, and recovered during login. Section 5 describes the first registration stage of the protocol, and Section 6 describes the second authentication stage of the protocol. Section 7 describes how to instantiate OPAQUE using different cryptographic dependencies and parameters."

But if you have some suggested wording to make this even more clear, let me know and I can incorporate it! 
Security:

• The export key export_key is (if I understood correctly),
  deterministically derived from PRF_K(pw). I simplify a bit here. This
  means the server can brute-force export_key. export_key is not as
  secure as a key that is, e.g., generated by the client running some
  keygen locally. This should be made super clear in the draft, imo. In
  particular, 10.1 states that export_key is a "pseudorandom value
  independent of other values in the protocol", and 10.5 says that it can
  be used to encrypt client secrets and store them on the server. The
  latter I find particularly alarming: the server can run long-term
  password guessing attempts against this encryption key, so I would
  specifically recommend to not use export_key as an encryption key when
  storing things on the server. Not sure if I'm too careful here, but
  people do tend to choose weak passwords...

Good point. In 10.1, I changed the text on export_key to say, "This key is a pseudorandom value derived from the client password (among other values) and has no influence on the security analysis (it can be simulated with a random output)."And in 10.5, I still wanted to capture the usage of the export key, and so I changed the text to the following:

"The export key can be used (separately from the OPAQUE protocol) to provide confidentiality and integrity to other data which only the client should be able to process. For instance, if the client wishes to store secrets with a third party, then this export key can be used by the client to encrypt these secrets so that they remain hidden from a passive adversary that does not have access to the server's secret keys or the client's password."

Let me know if this is still inaccurate. - Sec 4, "Future variants of OPAQUE may use different key recovery
mechanisms. See Section 4.1 for details." - Section 4.1 does not specify
any framework/constraints on what such mechanism need to fulfill, and I
would downtone this "invitation" to design one's own recovery mechanism.

I will simply delete this sentence -- I believe we added it in originally to address feedback that we got about choosing one specific recovery mechanism over another alternative, but I agree that at this point, such an exercise should be done with caution, and we don't want to actively recommend doing so (unless it comes with a proper security analysis). - Sec 10.1, first bullet. The "upcoming paper" is here:
https://eprint.iacr.org/2023/220
Added 

• Sec 10.1, second bullet. It is not true that this variant is analyzed
  in "the new paper", i.e., the paper mentioned in the first bullet. I
  have discussed this already with Hugo and he agrees.

Thanks, I simply removed the sentence: "This variant is also analyzed in the new paper referred to in the previous item." - Sec 10.2 Security Analysis. This section mentions that the security of
OPAQUE was proven in [JKX18]. However, the protocol proven there differs
in many ways from the protocol specified in this draft. As a starting
point, https://eprint.iacr.org/2023/843.pdf points out differences
between the proven version and the draft versions v03 and v09 (I did not
check whether all these still apply to v11).
I amended the first sentence to have the caveat: "Jarecki et al. {{JKX18}} proved the security of OPAQUE (modulo the design differences outlined in {{notable-design-differences}})" (referring to the previous section)
 Most importantly, [JKX18]
requires session identifiers not only for the overall OPAQUE protocol
but also for the VOPRF building block. However, the VOPRF as currently
specified in draft-irtf-cfrg-voprf-21 does not add unique session
identifiers to, e.g., hash inputs (which would be required for the
security analysis of both [JKK14] and [JKX18] to apply to a multi-user
VOPRF, and a multi-client OPAQUE). I discussed this with Chris and he
added the following disclaimer to the VOPRF security considerations
section of draft-irtf-cfrg-voprf-21:

"In [JKK14], these properties are proven for one instance (i.e., one
key) of the VOPRF protocol, and without batching. There is currently no
security analysis available for the VOPRF protocol described in this
document in a setting with multiple server keys or batching."

The same should be done in the OPAQUE draft, because for the specified
protocol, multi-client security is not proven anywhere in the
literature, afaik.

I see. At the end of this section, I added the paragraph: "In {{JKX18}}, security is proven for one instance (i.e., one key) of the OPAQUE protocol, and without batching. There is currently no security analysis available for the OPAQUE protocol described in this document in a setting with multiple server keys or batching."
 
Nits:

• the voprf draft is now a RFC and could be cited as such

I think it is not an RFC just yet (or at least I don't see an RFC number anywhere) - "describes the details of these stages in detail"

Thanks, changed to "describes the specifics of these stages in detail" - Sec 4, Create CleartextCredentials: client_public_key missing from the
inputs?

client_public_key is not stored in the struct because it is derived from client_private_key. But JP Aumasson also pointed out this confusion, and in response to his edits, I added the text: "A subset of these credential values are used in ..." 

Best,
Julia