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

Watson Ladd <watsonbladd@gmail.com> Fri, 19 July 2019 04:17 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9241200D7 for <cfrg@ietfa.amsl.com>; Thu, 18 Jul 2019 21:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGjOq-RWjlHU for <cfrg@ietfa.amsl.com>; Thu, 18 Jul 2019 21:17:18 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 567FA120043 for <cfrg@irtf.org>; Thu, 18 Jul 2019 21:17:18 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id c19so20754004lfm.10 for <cfrg@irtf.org>; Thu, 18 Jul 2019 21:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/e6WZg4Y0G5DinVv7+W486EJ8r0T7mnYUN4WAk7JOOU=; b=ay4+8WKMpvHum+p2BrZtMyGxC/UMlGUHr4Mdw+IHT9fj53V3fppS33gUsB21I1gprs C2nTXpSz4E9D6oHBntyg7ATfKPjng3nFCQyvOEpTpmyJsoiM9fo1I4kbaSQpNrgTCsMp tp2WvVN+CHclqiAGU6HnxQoE3S21rcyxdO//LBzGqgxoxzJRZYOXinVhD/4+9+cnFN+/ vnNyADWtiKXS3Cxzidr2wA2Gf5li9b7Wc0aI3BqJnCDEVJ81lhdONJa8PtRX7/SVezda 5lAZErpftPH4CY+oLhfRBVmJ+2NzAf87GlXS6jg35N3JggOiJg+z8QRb9FUuBgQ41xtG K2dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/e6WZg4Y0G5DinVv7+W486EJ8r0T7mnYUN4WAk7JOOU=; b=Du08P9GEtGqB99H5R70IUhbX46Vd6CZOzeHEfuwbwvgq7jfaj+/n36G5rAH9j7klMA SYK7yBu8VMFIgrbhkH0A2czVf62wsR3PpcHcp6ECJql+FOKfVPUNZ7FRr0goSA3kZrjt IKWMnIUoCxzSKgrwwctWDVb9F3l7SvlT3dU+jklHROPBDvaCtbdAd5/b/C6UAa4ag+mP V8tiLG5p+W35f9ZN3/eYRRs/2rRW1bBDKvhTeEcguM6vSNupzvSObAfHNqGAm7iptaGm HD74F0oUsauPBmTxULxsAuEaTqrEU1rDZ4QNmlFzpHGOFOsPc98306xbaCzzJE8PrDIz 1URg==
X-Gm-Message-State: APjAAAUjtYlD7aIugovHokcGTRGxA5G7Qwir8O6pYkfNrxldWuFrvkh0 uavckTL+LND/on6hZkILXf63h262HlneG23B84w=
X-Google-Smtp-Source: APXvYqzSfyt6Oso9UJyu8UbU2zImxLoA6yBG8b9P3Gb4Xwfd1GYjK1qZQgT3r2uXk4koihgu4/LVzCqbkOND5HIrtXE=
X-Received: by 2002:ac2:5442:: with SMTP id d2mr23765413lfn.70.1563509836559; Thu, 18 Jul 2019 21:17:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kxgX+gL7ABxiyDG6KiWdH0qe48R_jL+GHbQNsS0h6yYQ@mail.gmail.com>
In-Reply-To: <CAMr0u6kxgX+gL7ABxiyDG6KiWdH0qe48R_jL+GHbQNsS0h6yYQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 18 Jul 2019 21:17:04 -0700
Message-ID: <CACsn0ck5qTLp5kSuRaH9KA5Tw8UGa7Bgc7nE38fhYA36v=pHjA@mail.gmail.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Cc: CFRG <cfrg@irtf.org>, cfrg-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/XSU1XIxEKImTQuyt3sfFYfNR5J0>
Subject: Re: [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, 19 Jul 2019 04:17:22 -0000

On Thu, Jul 4, 2019 at 11:37 PM Stanislav V. Smyshlyaev
<smyshsv@gmail.com> wrote:
>
> 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), augmented.
>
> 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) 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
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.