Subject: [CFRG] Review: "The OPAQUE Asymmetric PAKE Protocol"

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 5 Sep 2021 19:08:13 +0000

His is my review of the version -06 of the Opaque draft

I did not find any smoking guns relating to security; I do have some questions about some of the design decisions (and if it’s too late to modify those design decisions, well, so be it)

  *   One plausible security goal is that an evesdropper listening to two authentications would not be able to determine whether they were for the same identity or not.  This protocol does appear to take some steps in that direction (by using the masking_key so that someone observing ke2 would be unable to determine that, at least, if all the client public keys and envelope data are the same length).  However, I cannot find any such protection for ke1 – adding such protection may be impossible (if the server can determine which client record to retrieve based on ke1 or data included with ke1, it would appear that an evesdropper should be able to as well, or at least well enough to determine whether two different records were being accessed).  Is such anonymity a security goal of this protocol (and if so, how does it achieve it)?  If that is not a security goal, what is the purpose of masking_key?
  *   I note that to encapsulate an envelope, Opaque uses a MAC and the ENCRYPT paradigm; is there a specific reason for this design decision?  Nowdays, it is generally recommended that people use an AEAD, and if they can’t, then we generally find that an ENCRYPT and then MAC paradigm to be less error prone.
  *   In protocol overview, it notes that registration requires “an authenticated and confidential channel”.  The requirement for authentication is obvious; is there a hard requirement for confidentiality?  Is there a known problem that could happen if confidentiality was not provided (possibly related to the anonymity question I have above)?  Does the proof of the protocol require confidentiality (even without a demonstration of a known exploit)?  Or, are the authors being cautious (if you have authentication, adding confidentiality is usually fairly easy)?

From: Crypto-panel <[email-masked]> On Behalf Of Stanislav V. Smyshlyaev
Sent: Wednesday, August 11, 2021 10:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Crypto-panel] Request for review: "The OPAQUE Asymmetric PAKE Protocol"

Dear Crypto Panel Experts,

We've obtained a request for review of version -06 of the "The OPAQUE Asymmetric PAKE Protocol" draft, draft-irtf-cfrg-opaque-06 (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque-06).

The chairs would like to ask the Crypto Panel to provide a review of this document. The Crypto Panel experts reviewed OPAQUE a number of times during the PAKE Selection Process: during both Round 1, see https://github.com/cfrg/pake-selection#overall-reviews-by-crypto-review-panel, and  Round 2, see https://github.com/cfrg/pake-selection#reviews-by-crypto-review-panel-round-2. The draft was later adopted by the CFRG based on the results of the Selection Process.

The authors have provided a document with replies to the questions asked in previous reviews: https://docs.google.com/document/d/18B_nXbyjukTB9rR7qEj8-LiNAZDRssDxyhxT0-JzwPc/edit#heading=h.owtmbbgjiae1

Any volunteers?

Stanislav (on behalf of the CFRG Chairs)