[CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13

["Hao, Feng" <[e-mail]>]

Hi Riad, Kevin,

Thanks for your comments. I will reply to you both here. 

@Riad, please note that the undetectable online dictionary attack is different from the (standard) online dictionary attack. The "completely standard attack detection heuristic" applies to the latter only. For example, SRP-6a is not vulnerable to the undetectable online dictionary attack. The standard rate-limiting measure used in SRP-6a will not work in OPAQUE.

@Kevin, you proposed adding mitigating measures to the implementation rather than directly addressing the weakness in the protocol. I don't think that's the right approach, but this is only my personal opinion.

@Both, have a look at the robustness principles for public key protocols by Anderson and Needam at CRYPTO'95 (https://www.cl.cam.ac.uk/~rja14/Papers/robustness.pdf) in particular,

"Principle 3: Be careful when signing or decrypting data that you never let yourself be used as an oracle by your opponent."

Here, OPAQUE lets the server be used as an oracle (without client authentication). This violates this principle and is dangerous in my view. Again, have a look at SRP-6a, which doesn't have this problem, so you can compare side-by-side. There are many similar examples of protocol failures explained in Anderson-Needham's paper and good lessons that should be learned. 

Regards,
Feng

From Riad

> What you are calling complicated is in fact a completely standard attack detection heuristic. Password-based authentication should always be rate limited because passwords may have low entropy. When an attack is detected, some flavor of rate limiting must be applied. This is true even when the attack is detected via a mechanism that can distinguish between attacks and network failures.

> So your point is really just that one could sometimes avoid rate limiting by distinguishing between attacks and network failures, and that doing so helps clients with bad network connections. This is nice, but it's not a security property: deciding not to rate limit when the server detects a network failure is more reasonably categorized as a mild optimization.

> And it's not obviously a useful one. As anyone who has an SSH server on a public IP knows, the vast majority of failed logins are attacks. So in any case if I were deploying a network service I wouldn't relax my rate limiter for network failures. First, this is unnecessary optimization for a rare corner case. Second, I am not at all convinced that "authentication succeeds and network drops repeatedly" isn't just another flavor of attack.
Tarpit first, ask questions later.

From Kevin

> Hmm, I don't think I would characterize the situation you describe as an undetectable online dictionary attack, or a security concern, for the OPAQUE protocol itself. This would only be an attack surface if an application server built on top of OPAQUE chooses not to track password authentication attempts, and optimistically assumes that a client not responding after the second message means that they "dropped out". But, if the server treats all incomplete message exchanges as authentication failures, then there is no attack; only the risk of legitimate users being locked out.

> However, for this latter concern, there are a bunch of things that the server can do to mitigate this risk. For instance, the server can raise the threshold of allowed password attempts from a single IP address/device to a larger number (say, 20) before the client is locked out. It might be very unlikely that a legitimate user attempts to connect 20 times, successfully receiving the second message but failing to transmit the third message each time, though of course this depends on the application setting. For servers that wish to tolerate a smaller threshold (say, 5): if the client drops out after the second message, they can cache the first message and replay the first message again to the server. If the server also caches their response to the first message, then this allows the server to simply return the cached second message without having to regenerate it. Now of course this may not apply to some application scenarios if it is not possible for the client or server to keep these caches around. But I wanted to highlight some of these options as they provide alternatives that can be addressed by the application layer.

> At any rate, we do not think that this requires changing any part of the OPAQUE protocol (for example by adding a fourth message) to handle this. Hope that makes sense!