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

["Riad S. Wahby" <[e-mail]>]

Hello Feng,

"Hao, Feng" <Feng.Hao=[e-mail]> wrote:
> The counter-based threshold control at the server can get far more
> complicated than what you describe because of the “undetectable” nature
> of this online dictionary attack – the server can’t distinguish legitimate
> drop-outs (say due to network delay or error) and illegitimate ones (say an
> attack), and hence can’t reliably define what’s meant by an authentication
> failure.  Legitimate users may be locked out of their accounts, not because
> of using the wrong password, but because of the data retransmissions in
> a slow network. I should highlight that SRP-6a is not subject to this
> attack, and is more secure in this regard.

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.

-=rsw