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

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

Hi Kevin,

Your description of the issue is accurate. Thanks for doing that.

As you may be aware, any system that follows this default countermeasure will risk causing the Denial of Service attack to its own legitimate users. For most businesses, I’m fairly certain that’s unacceptable.

I think you have done your best. There is probably nothing more you can do in the text.

Cheers,
Feng

From: Kevin Lewi <[e-mail]>
Date: Tuesday, 28 May 2024 at 19:04
To: Hugo Krawczyk <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, Hao, Feng <[e-mail]>, IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
Hi all, some additional text has been added to the draft to address the above discussion, under the Implementation Considerations section on handling online guessing attacks:

"Additionally, note that a client participating in the online login stage
will learn whether or not authentication is successful after receiving the
`KE2` message. This means that the server should treat any client which fails to
send a subsequent `KE3` message as an authentication failure. This can be handled
in applications that wish to track authentication failures by, for example,
assuming by default that any client authentication attempt is a failure unless a `KE3`
message is received by the server and passes `ServerFinish` without error."

(see https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/456)

We believe the right way forward is to address this by offering ways to mitigate the attacks through the server's actions rather than directly modify the OPAQUE protocol itself.

Hope this makes sense, and let us know if you think any of the wording should be adjusted.

Thanks,
Kevin

On Mon, May 27, 2024 at 3:54 PM Hugo Krawczyk <[e-mail]<mailto:[e-mail]>> wrote:
There is an even better reason not to go with what Feng proposes. His modified protocol is insecure. To achieve the property that the server learns first whether the password was wrong, you would need to move auth_tag to the fourth message and that modified protocol is insecure (in the real sense of insecure, not as Feng's "undetectable attack").

Let's move on.

Hugo

On Mon, May 27, 2024 at 6:47 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:


On Mon, May 27, 2024 at 3:15 PM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:
Hi Eric,

What I propose is to remove the key confirmation string sent by the server in the 2nd pass. The client sends its key confirmation in the 3rd pass, and the server only sends its key confirmation string in the 4th pass. This will be a revision in the protocol spec. I couldn’t see how adding a piece of text could properly address this issue.

Thanks for the explanation.

I don't see this as a realistic proposal, as it would mean that OPAQUE would not be able to fit into TLS 1.3 without significant surgery to the TLS 1.3 core, which is obviously undesirable for deployment reasons. It seems to me that we do want it to be possible to use PAKEs with TLS 1.3, and if the choices are to accept this property or to make big changes to TLS 1.3, then I think the right answer is probably to accept this property and document it in the specification.

-Ekr


Cheers,
Feng

From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Date: Monday, 27 May 2024 at 23:00
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: Watson Ladd <[e-mail]<mailto:[e-mail]>>, IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
Feng,

This has been a very long thread, with a lot of back and forth, but it's not clear to me what outcome you are looking for here.

Do you have a proposed piece of text that you think should be in the OPAQUE draft prior to it going to RFC? If so, what is that text?

-Ekr


On Mon, May 27, 2024 at 2:32 PM Hao, Feng <Feng.Hao=[e-mail]<mailto:[e-mail]>> wrote:
Hi Watson,

That will be a standard online dictionary attack which applies to any PAKE, and can be detected and “accurately” recorded by the server. Please have a look at Ding and Horster’s 1995 paper which I posted earlier. https://dl.acm.org/doi/pdf/10.1145/219282.219298 That paper explains the difference between a standard (detectable) online dictionary attack and an undetectable online dictionary attack. Similar attacks in various different protocol settings have been well studied in the past 30 years.

Cheers,
Feng

From: Watson Ladd <[e-mail]<mailto:[e-mail]>>
Date: Monday, 27 May 2024 at 21:49
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: Riad S. Wahby <[e-mail]<mailto:[e-mail]>>, IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
On Mon, May 27, 2024 at 6:13 AM Hao, Feng
<Feng.Hao=[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi Riad,
>
>
>
> The factual difference between OPAQUE and SRP-6a is that in OPAQUE, the server is authenticated first, whilst in SRP-6a, the client is authenticated first. The order of authentication has a profound implication in security here. For the case of OPAQUE, the server leaks password verification information via the key confirmation string in the 2nd pass before the client is authenticated. If the client drops out, the server can’t distinguish legitimate drop-outs from online guessing attacks. This means that the server has to deal with false positives (denying legitimate users hence causing the DoS attack to its own users) and false negatives (letting an attacker guess the password without being detected or logged). Managing the false positive and false negative can be complicated in practice.

Huh? An attacker can always carry out the full protocol to guess to
lock someone out. That a query amounts to a guess doesn't really
change this.

--
Astra mortemque praestare gradatim
_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>