search

cfrg / draft-irtf-cfrg-voprf

Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups
https://cfrg.github.io/draft-irtf-cfrg-voprf/#go.draft-irtf-cfrg-voprf.html
Other
39 stars 15 forks source link

First cut at Patton's review #318

Closed chris-wood closed 2 years ago

chris-wood commented 2 years ago

Thanks for the review, @cjpatton! This PR tracks changes to most of your suggestions, with some tweaks.

I took most of your editorial and protocol change suggestion as they were great. I reworked the security considerations section to remove unhelpful jargon and focus on applications and implementers. I'd like to call your attention to the {{limits}} section, which tries to collapse much of the previous text into a straightforward description of the static DH problem and its impact on the group security level.

Right now I don't have any good ideas for sharpening the application guidance against this problem beyond what's there. ("If you admit an oracle and want more than 128 bits of security, use a larger group.") I would welcome concrete suggestions for improving the text here.

cc @tomrist, @nirvantyagi for 👀 on the new security considerations, too, which you can find rendered here.

cc @kevinlewi, @bytemare for 👀 regarding other editorial changes.

Closes #317. Closes #316. Closes #315.

chris-wood commented 2 years ago
  1. For applications we know about, such as OPAQUE or PrivacyPass, say whether the static DH is exposed, and how.

As above, I don't think we should describe that in this document.

  1. Say that applications can partially mitigate attacks that use a static-DH oracle by rate-limiting requests from clients.
  2. RECOMMEND frequent key rotation.

These can be harmful for some applications, so I'll just note them as possibilities.

chris-wood commented 2 years ago

@cjpatton addressed your comments!