search

cfrg / draft-irtf-cfrg-opaque

The OPAQUE Asymmetric PAKE Protocol
https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html
Other
100 stars 20 forks source link

Addressing comments from ISRG review #470

Closed kevinlewi closed 6 days ago

kevinlewi commented 1 week ago

See https://mailarchive.ietf.org/arch/msg/cfrg/dkobloepKBl8kmpcyMb71rX03ms/

And the responses:

  1. Updated
  2. Updated
  3. Changed, but simply removed the word “hence” instead of adding a comma between “hence” and “determined”
  4. Added notes that “This is equivalent to the Blind/Finalize function described in Section 3.3.1 of {{RFC9497}}.”
  5. Updated
  6. I think that how the session_key gets used as the output of the key exchange is outside the scope of this document. We added clarification for the usage of export_key because it is an atypical output for key exchange, but we expect session_key to be more well-understood. Additionally, it is difficult to arrive at a consensus for how session_key is used, since it is likely to be application-specific. However, unless others chime in with the opinion that a subsection on Session Key Usage should be added to the document, we are omitting further explanation of this parameter in the draft.
  7. Changed, since creds/credentials was the only mismatch, we instead just updated the diagram to use “credentials” rather than “creds”.
  8. Both options are acceptable and I think it is application-specific as to which is preferable. The advantage to using separate server_private_key parameters for different clients is to allow for domain separation and enable smoother key rotation. However, these are optional benefits, since the drawback is that the server has to store more key material if it is per-client.
  9. Updated. The same fake record should be returned. The text has been modified slightly to hopefully make this more clear: “It is RECOMMENDED that a fake client record is created once (e.g. as the first user record of the application) and then stored alongside legitimate client records, to serve subsequent client requests. This allows servers to retrieve the record in a time comparable to that of a legitimate client record.”
  10. Updated, to point to the Security Analysis section.
  11. Updated, amended the text to say “with previous UC security modeling”.
  12. The convention we follow for each of these pseudocode function definitions is to simply list the exception cases but not actually incorporate them into the function descriptions.
  13. Updated