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

[Eric Rescorla <[e-mail]>]

This looks good. Perhaps add after "receiving the KE2 message"

"This allows the client to verify a guess at the password without sending
KE3, thus leaving some ambiguity about whether the client has the wrong
password or experienced a network error".

I think it would be OK as-is, however.

-Ekr


On Tue, May 28, 2024 at 11:04 AM Kevin Lewi <[e-mail]> wrote:

> 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 3
>>>> rd pass, and the server only sends its key confirmation string in the 4
>>>> th 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]
>>
>