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

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

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.

Cheers,
Feng

From: Eric Rescorla <[e-mail]>
Date: Monday, 27 May 2024 at 23:00
To: Hao, Feng <[e-mail]>
Cc: Watson Ladd <[e-mail]>, IRTF CFRG <[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]>