[Cfrg] PAKE selection process: status after Phase 1 and following steps

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear CFRG,

The first phase of the PAKE selection process is over.

We've obtained the following nominations (by e-mails directly to the chairs
or to the CFRG mailing list).

   - SPAKE2 (nominated by Watson Ladd and Benjamin Kaduk), balanced;
   - OPAQUE (nominated by Hugo Krawczyk), augmented;
   - J-PAKE (nominated by Feng Hao), balanced;
   - SPEKE (nominated by Dan Harkins), balanced;
   - AuCPace (nominated by Björn Haase), augmented;
   - CPace (nominated by Björn Haase), balanced;
   - VTBPEKE (nominated by Guilin Wang), augmented;
   - "SPAKE2+EE with blind salt"/BSPAKE (nominated by Steve ([e-mail]),
   augmented.

Please send an e-mail to [e-mail] if your nomination was lost
or, on the contrary, if your personal opinion about good properties of some
PAKE was misinterpreted as a nomination.
Also, please let the chairs know if some of the proposed questions to be
considered is not present in the list further in the current message
(several groups of questions were merged, since essentially they were about
the same things - but if some parts have been lost, please let the chairs
know, so the list will be updated before the end of phase 2 of the
selection process).


Dear Watson, Benjamin, Hugo, Feng, Dan, Björn, Guilin and Steve,

According to the plan of PAKE selection process, now we're on phase 2,
which will last until the 19th of July.
To give the reviewers (on the future steps of the process) as much
information about each PAKE, as possible, the designers of the protocols
(or the persons who nominated them) should prepare papers (as separate PDFs
or just in a form of a message to the CFRG mailing list or to the CFRG chairs)
with:
a.      expanded answers for all positions of RFC 8125 regarding their
PAKEs;
b.      their own opinions on the following questions (they does not need
to be complete: for example, a designer of a PAKE might not be an expert in
TLS and might not be able to reply how his PAKE can be incorporated in TLS
1.3):

   - How does it meet the "SHOULD" requirements of RFC 8125?
   - Does it meet "crypto agility" requirements, not fixing any particular
   primitives and/or parameters?
   - What setting is the PAKE suitable for, which applications does it
   have?
      - "Peer communication" (where both ends share the same password) or
      "client-server" (where the server does not store the password but only a
      one-way function of the password)?
      - A nomination should specify for which use-cases the protocol is
      recommended ("PAKE as a more-secure replacement for a PSK on a
      machine-2-machine interface" or "PAKE for securely accessing a remote HMI
      interface server (e.g. a web server) without configured WEB-PKI
      certificates").
      - Can two communicating parties initiate the key exchange process at
      the same time, or must it always be the case that only one party can
      initiate the process?
      - Is it suitable to be considered as a standalone scheme?
      - Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
   - Is there a publicly available security proof? If yes,
      - Are there known problems with the proof?
      - Is the considered security model relevant for all applications that
      PAKE is intended for (e.g., if a PAKE is to be used in TLS
Handshake, it is
      important that the TLS adversary model is considered for the PAKE)?
      - Does it allow to be sure in sufficient level of security for common
      values of password lengths?
   - Security assessment.
   - Does its security depend on any nontrivial implementation properties?
      Are they clearly stated in the document?
      - Does the PAKE have precomputation security (for augmented PAKEs)?
      - If the PAKE relies on the assumption of a trusted setup - more
      specifically, the discrete logarithm relationship between the two group
      elements in the system setup MUST be unknown - in anticipation
of the worst
      but not impossible scenario, the authors should clearly state
the security
      implications when the discrete logarithm relationship becomes known, and
      the subsequent mitigation measures.
   - Performance assessment.
   - What's with the “round efficiency” of the PAKE? In a standard
      two/multi-party secure computation setting, the “round” is defined as a
      step in which all parties can complete operations at the same
time without
      depending on each other. In practice, a 2-round protocol could be
      implemented as 2 flows or 3 flows depending on the application
context, but
      that’s more the implementation detail.
      - How many operations of each type (scalar multiplications,
      inversions in finite fields, hash calculations etc.) are made by
each side?
   - Which recommendations for secure usage can be given?
      - Is it defined how the explicit key confirmation is performed/must
      be performed externally? Are there clear statements whether this
procedure
      is optional or mandatory?
      - Can any recommendations on using iterated hashing (e.g., with
      Scrypt) with the PAKE be given?
      - Can any recommendations to avoid a user enumeration attack be given?

Best regards,
Stanislav Smyshlyaev