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

[Kevin Lewi <[e-mail]>]

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]>
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]> wrote:
>
>>
>>
>> On Mon, May 27, 2024 at 3:15 PM Hao, Feng <[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]>
>>> *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]> 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]>
>>> *Date: *Monday, 27 May 2024 at 21:49
>>> *To: *Hao, Feng <[e-mail]>
>>> *Cc: *Riad S. Wahby <[e-mail]>, IRTF CFRG <[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]> 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]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>> CFRG mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>