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

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

That makes the server subject to an undetectable online dictionary attack.


From: Hugo Krawczyk <[e-mail]>
Sent: 21 May 2024 14:21
To: Hao, Feng <[e-mail]>
Cc: IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

Yes.
On Tue, May 21, 2024, 04:01 Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:

Does OPAQUE send any key confirmation string in the second message?

From: Hugo Krawczyk <[e-mail]<mailto:[e-mail]>>
Sent: 21 May 2024 04:02
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

Sorry Feng. You are wrong about the need for a 4th message in OPAQUE. Full forward secrecy (against passive and active attackers) is provided by the 3-message protocol as documented in the paper's full version and in this draft. The undetectable online attack you refer to in your paper has nothing to do with forward secrecy or the need of a 4th message in OPAQUE.


On Mon, May 20, 2024 at 4:16 AM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:
Hi Hugo,

The cases of achieving forward security in TLS 1.3 and OPAQUE are different. Please allow me to elaborate.

You introduced the weak/strong definitions of forward security in your 2005 HMQV paper. For a two-message AKE scheme with weak forward security, strong forward security can be obtained by sending a third message (to complete mutual authentication with explicit key confirmation). By “full forward security” in the updated OPAQUE paper on IACR e-print, I believe you refer to the strong notion since the paper mentions “against active attacks”.

TLS 1.3 provides weak forward security in 1-RTT and requires 3 messages to achieve strong forward security. The OPAQUE paper follows the same.

However, in TLS 1.3, the server holds a strong secret. But in augmented PAKE, the server holds a weak secret. This difference is crucial.

As a result, the 3-message OPAQUE scheme with strong forward security is insecure as it’s vulnerable to an undetectable online dictionary attack. To prevent this attack, OPAQUE needs to be revised to require 3 messages to provide weak forward security, and 4 messages to achieve strong forward security.

Therefore, the change from 2-message OPAQUE to 3-message OPAQUE has nothing to do with forward security (weak or strong). This revision in the protocol spec is necessary to prevent the undetectable online dictionary attack (which is a known attack in the PAKE literature but seems not covered in the original formal model and analysis in the 2018 OPAQUE paper). This attack doesn’t apply to TLS 1.3 because the TLS server holds a strong key (as opposed to a weak one).

PS. We explained the undetectable online dictionary attack in our FC’24 paper (https://eprint.iacr.org/2023/768.pdf) To the best of my knowledge, this attack was not discussed during the PAKE review of OPAQUE.

Regards,
Feng

From: Hugo Krawczyk <[e-mail]<mailto:[e-mail]>>
Sent: 17 May 2024 04:16
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

The common definition of forward security, and the one followed in the internet draft (and paper), is that session keys remain secure (after being deleted) even upon the compromise of long-term key material in the future. In the case of aPAKEs, forward secrecy applies to the password, namely, a future leakage of the password does not compromise past session keys. This is achieved by OPAQUE in 3 messages (similar to the way that TLS 1.3 achieves forward security in 3 messages).

Hugo

On Thu, May 16, 2024 at 3:49 AM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:
Hi Hugo,


>  As for the 3-message issue, to address your concern, we intend to add the following sentence to the noticeable differences (with OPAQUE paper) section:


>  - The AKE describes a 3-message protocol where the third message includes client authentication material that the server is required to verify. This change (from the original 2-message protocol) was made to provide explicit client authentication and full forward security. The 3-message protocol is analyzed in the full version of [JKX18].

Sorry for my delayed response on this. If you want full forward security in the strong sense (with explicit mutual key confirmation), you will need 4 messages for OPAQUE, not 3. You can’t do explicit key confirmation in the 2nd pass. So the client sends its explicit key confirmation in the 3rd pass, and the server can only send its explicit key confirmation in the 4th pass. That takes 4 passes in total. As explained earlier, the reason that we may call OPAQUE a 3-pass scheme is entirely because 3 passes are the minimum required to finish client-to-server authentication for an augmented PAKE in a client-server setting and that the client needs to be authenticated first. At the end of the 3rd pass, the authentication from the server to the client is still implicit. I would suggest you remove the “and full forward security”. The claim of full forward security for the 3-message OPAQUE in the full version of the paper may need to be updated as well.

Regards,
Feng