[Cfrg] Updated review of PAKEs

Bjoern Tackmann <bjoern.tackmann@ieee.org> Sun, 08 March 2020 22:23 UTC

Return-Path: <bjoern.tackmann@ieee.org>
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 741AB3A08FD for <cfrg@ietfa.amsl.com>; Sun, 8 Mar 2020 15:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rv-mSIwjuzGl for <cfrg@ietfa.amsl.com>; Sun, 8 Mar 2020 15:23:13 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 7F0CB3A08F9 for <cfrg@irtf.org>; Sun, 8 Mar 2020 15:23:13 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id v4so8741003wrs.8 for <cfrg@irtf.org>; Sun, 08 Mar 2020 15:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=KNnpj2UQCRS0P03UrHnLL1vsk55OM6oj9NOpInCtvGI=; b=PQNqwr/X92ar6RbM4ESTP2dtRdRhyW7JIonl3bpA8N9rRb21wua7NS/c+vWU+DfXIv g3rsu/QOP16emMJni36x4uoH6/cLkceG337NX2XEj4xCfo8vkgMd1b5xjkEk+gAI4qwa O8ih0VgR3HMVt0gJq5RhBIDKVlyxy/4VDzJaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=KNnpj2UQCRS0P03UrHnLL1vsk55OM6oj9NOpInCtvGI=; b=bxvM8CuxQCcLcHwQlydQbvbYIBufNQnnTjfiBVwF66v+kqQkIs7OPbd90+v/IBpHGs OXiYsIRhFLMkMfXQG0eUG4mwZhFIoUsaTI+QMX4cz5rnCfY2Ur+gT9F1g1Ua0GD7sPPk Ljaa6hnGIBToaibjWNPt5a7VgHgUrViChs+VlYLNOukymoKQLA8mximA+Tv8nStv2373 ZmJ1Rjacf54vsObEmGjh6WgCP/4SJc40YSC+639FK9Y/J1prCoC5bZyrdOV4ayiJZdOo mUpYFMmf7DCWQXmlz4gGYSmsomnAlK4b+wvVlSXcPGMNM+VRGmwISa7YqPUFEYn48D5p hMhg==
X-Gm-Message-State: ANhLgQ29cqD8mYtIkYoGT5KR6RrFjG9sekwVVgiUkuAKXr6Hn32W4ZRg 67HJPmiTGfUnf1vXmpqhH0kTnp5nc1g=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vv6RsnCjvuQXY6H9bmAGD+DV9NcaIZhk96U+BUr?= =?utf-8?q?LSbm5yD8/GJOT9e5ZOJcjQqOxFPdvdx+lQ=3D=3D?=
X-Received: by 2002:a5d:608e:: with SMTP id w14mr17813093wrt.201.1583706191125; Sun, 08 Mar 2020 15:23:11 -0700 (PDT)
Received: from ?IPv6:2001:8e0:2002:8600:d1be:cfeb:46e6:ee56? ([2001:8e0:2002:8600:d1be:cfeb:46e6:ee56]) by smtp.gmail.com with ESMTPSA id l3sm58807309wrq.62.2020. for <cfrg@irtf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2020 15:23:10 -0700 (PDT)
From: Bjoern Tackmann <bjoern.tackmann@ieee.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <02E5DBB7-10F9-4595-94D2-9F3A96F5AE46@ieee.org>
Date: Sun, 8 Mar 2020 23:23:09 +0100
To: cfrg@irtf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/eo8O6JYPmWY6L9TlcIXStFy5gNQ>
Subject: [Cfrg] Updated review of PAKEs
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: Sun, 08 Mar 2020 22:23:16 -0000

This is a brief update of my review of all candidates sent on October 29 [1]. Note that there was a follow-up discussion in which Hugo pointed out flaws in my report. (None of them had an effect on the outcome.)

Balanced PAKE

The short version is that I prefer CPACE over SPAKE2. The arguments are essentially the same as in the previous review. SPAKE2 seems an (almost) equally good alternative, and picking one of the two was difficult.

Sparked by Julia’s excellent review of the proofs [2], I wanted to share some of my own thoughts on this in a bit more detail. I fully support Julia’s argument that SPAKE2 has a published proof that is written clearly and in detail, and that has withstood scrutiny since 2005. The CPACE proof, by contrast, omits several important steps (such as all reduction arguments), has been more of a moving target during review, and has been published only last year. The SPAKE2 theorem is in concrete security (which I think is an important aspect), whereas the CPACE theorem only provides an asymptotic “soundness” guarantee. And yet, the formal statement for SPAKE2 has the assumption of uniformly distributed passwords; the protocol does not seem to use this anywhere but it is still a limitation in the proof support. It is also unclear how the proved security of SPAKE2 composes when the key is used in higher-level protocols. And last but not least, I think (disclaimer: what follows is not a statement I can make formal) that the dependency on stronger idealization in the proof of CPACE is linked to the use of a security model that is significantly stronger in corruption modeling. So in terms of proof support I find the two protocols incomparable, and my preference for CPACE mostly comes from the “more useful” (targeted) security statement. I fully understand Julia’s reasons for coming to a different conclusion.

Finally, and although it may be unnecessary to point this out: even subtle changes in protocols invalidate existing security proofs. I think it would be prudent for CFRG to re-evaluate the proof support after the now-discussed modifications to the chosen protocol (e.g., choice of session id for CPACE, choice of M,N for SPAKE2) are finalized, before deciding on the final outcome (“zero or one” candidates) of the process.

And just for completeness: I deliberately did not take possible IP issues into account.

Augmented PAKE

The short version is that I prefer OPAQUE over AUCPACE. The main arguments are OPAQUE’s better compatibility with important application protocols through less protocol messages, and its flexibility.

Amending my previous review, the latest proof for OPAQUE is indeed a significant improvement over the one that was available when I started that review. So besides the preferable properties stated above, I now consider the proof support for OPAQUE also as better than that for AUCPACE. (This is in full agreement with Julia’s assessment.)

[1] https://mailarchive.ietf.org/arch/msg/cfrg/1sNu9USxo1lnFdzCL5msUFKBjzM/
[2] https://mailarchive.ietf.org/arch/msg/cfrg/47pnOSsrVS8uozXbAuM-alEk0-s/