Static DH oracle text

[chris-wood]

We should ensure that we acknowledge this type of attack in theory, and describe how OPAQUE deals with it. In particular, since each OPRF key is per-user, which means that any reduction in security is per-user, which is unlikely to be a problem in practice.

[hugokraw]

There is text in the security considerations section about this but it contains an error: A later paper by Cheon shows that one does not need the exponential memory. Also, we need to provide a reference to Taylor Campbel's comprehensive note on this. It is also worth noting Loup Vaillant observation on communication time (with the OPRF server), lower bounded by speed of light, given that this attack is inherently sequential. Maybe you will summarize these things in the OPRF draft and then we only refer to the fact that in OPAQUE kU is per user so this (anyway infeasible) attack would be directed to enable a dictionary attack against a single user.

[chris-wood]

After reviewing this again, I'm inclined to remove most of the text in this section and simply delegate it to the OPRF draft. Would the following work, @hugokraw?

While one can expect the practical security of the OPRF function
(namely, the hardness of computing the function without knowing the
key) to be in the order of computing discrete logarithms or solving
Diffie-Hellman, Brown and Gallant {{BG04}} and Cheon {{Cheon06}} show an
attack that slightly improves on generic attacks. However, in this case of OPAQUE,
these attacks are not practical as the number of queries translates to an equal 
number of failed authentication attempts by a single client. Therefore, the amount
of work required of an attacker scales linearly with the number of target clients.

[hugokraw]

A bit edited: While one can expect the practical security of the OPRF function (namely, the hardness of computing the function without knowing the key) to be in the order of computing discrete logarithms or solving Diffie-Hellman, Brown and Gallant {{BG04}} and Cheon {{Cheon06}} show an attack that slightly improves on generic attacks. For typical curves, the attack requires an infeasible number of calls to the OPRF and/or results in insignificant security loss (see oprf-rfc). For OPAQUE, these attacks are particularly impractical as they translate into an infeasible number of failed authentication attempts directed at individual users.

(Note: It is true that the attack scales linearly with the number of target users, but writing it that way it feels like a feasible attack. After all scaling linearly in the number of users is not a terrible limitation of attacks. The point here is that even for a single user it is totally infeasible; while"just being linear" may obscure that fact. )

[chris-wood]

Perfect! PR incoming.