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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Fri, 05 July 2019 06:37 UTC

Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0CF5E120179 for <cfrg@ietfa.amsl.com>; Thu, 4 Jul 2019 23:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IzLM1gTLurhw for <cfrg@ietfa.amsl.com>; Thu, 4 Jul 2019 23:37:18 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9BF120223 for <cfrg@irtf.org>; Thu, 4 Jul 2019 23:37:17 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id x25so1395945ljh.2 for <cfrg@irtf.org>; Thu, 04 Jul 2019 23:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=b/64IY0iye2gLOBKfL11V1i4tdR0+Lvd8fKlgffzmik=; b=puXK8LOIHyZYLA+83zJYgua9DC9jUWR++ejOu9VISWU9YprRRa/pdUOk2w4J1hGcwG VG5WfywVA0dAGnawEBA715pQ/cKhHYtG5vSrO0WQY1BzqVlwlzVzmXMCWnAcUpSI46PC 8xzuP0YSM/JnSkwaACxfF1V6lOHQT61GIRG4loi+jPIvI+9l8pmSA/XzpazU32gTzIPI AnIA/mEoPhp0x8xGcxg0l5NP28v+ASjMie7KArXhQeQku7Hm9lK9AIEVKurFWL8u0Q5K HUGPz5HUyF0n16SMgCukNCAaZ6gHxGCvvaCZBJEt4wNrIP9RS6dVRdVeCOtTha7M2mGR X1VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=b/64IY0iye2gLOBKfL11V1i4tdR0+Lvd8fKlgffzmik=; b=AY4TLgeWou5Gsu1YDyauIp+iuwkVWXzloW1zxaPQ5/+FMQNWMZmua48txSVpLbdKgR 03SnfUuAEWIfApG6yLEXUIPxDv0WAy4ob0V5sneiCnkKy87V3mjQfMVsUluoT7zsGz48 iTD4n7kKLcYJBkWXATrhuMNoAL2pXgaCJJkY91LONphtqnXvsv8pfIUvAXHPj+jIRFNP 4S8pZ3szlT4Gwzj5HtMZhejjJjyTN/8qGvACfHwJuYAS5cN1DUqY+dftAwZ0b2k1u8ma HCf90MpZiFXPNlBVMRFDzyBrYfYb3uQH6TBgWZgYAdZDNx1UypBItcildBo3RD96dcS/ bf7g==
X-Gm-Message-State: APjAAAWxFCiDRO+vjZ/rhE4kZDSVuNBLrbxHjyM+S8GRpS5Y4P4I81ub x6uYs33sw63fFd2NKIOE/6tz4V+HmpcvBA98benVujNpmmxlSw==
X-Google-Smtp-Source: APXvYqxJBTjnLW95/bc516SZJ7h1LzEoVm5y0j2QP30Pbd16qVJlBHVkwSYMUGpZgwV0BbZJs3kgxpYkOk2998cGftQ=
X-Received: by 2002:a2e:98d7:: with SMTP id s23mr1124349ljj.179.1562308635554; Thu, 04 Jul 2019 23:37:15 -0700 (PDT)
MIME-Version: 1.0
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Fri, 5 Jul 2019 09:38:38 +0300
Message-ID: <CAMr0u6kxgX+gL7ABxiyDG6KiWdH0qe48R_jL+GHbQNsS0h6yYQ@mail.gmail.com>
To: CFRG <cfrg@irtf.org>
Cc: cfrg-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004074f1058ce953e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/usR4me-MKbW4QO0LprDKXu3TOHY>
Subject: [Cfrg] PAKE selection process: status after Phase 1 and following steps
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2019 06:37:21 -0000

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 (steve@tobtu.com),

Please send an e-mail to cfrg-chairs@ietf.org 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)
a.      expanded answers for all positions of RFC 8125 regarding their
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

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