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

[Hugo Krawczyk <[e-mail]>]

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]
>