[Cfrg] Personal feedback regarding the CFRG PAKE selection process

Björn Haase <bjoern.m.haase@web.de> Tue, 19 November 2019 23:19 UTC

Return-Path: <bjoern.m.haase@web.de>
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 90B871208AC for <cfrg@ietfa.amsl.com>; Tue, 19 Nov 2019 15:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fcwvnz2nJ3Gb for <cfrg@ietfa.amsl.com>; Tue, 19 Nov 2019 15:19:01 -0800 (PST)
Received: from mout.web.de (mout.web.de []) (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 00E5F120882 for <cfrg@irtf.org>; Tue, 19 Nov 2019 15:19:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1574205536; bh=F1857D9BrrujFofl8pSDShz5s6qNCYxdmuZRAboO6E4=; h=X-UI-Sender-Class:From:Subject:To:Date; b=Ck9dQ7j7Xkkz/5XLei6fZoIrVzFI6mc3m5lHvDGnIVZYk1GJtDpdagJ3wvMX63fCs khmFlGsngknmvX6U10rc8r95o2Xv2J3z3xhWq9NwPoJtMI585KippyOi8P1FfzVc69 8WJGyP6MZ7LvAlFYuBszdL0P2IrMvzSnaWkB6TiY=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by smtp.web.de (mrweb101 []) with ESMTPSA (Nemesis) id 0LkPrz-1i1ArF1Fkp-00cP6n for <cfrg@irtf.org>; Wed, 20 Nov 2019 00:13:50 +0100
From: =?UTF-8?Q?Bj=c3=b6rn_Haase?= <bjoern.m.haase@web.de>
To: cfrg <cfrg@irtf.org>
Message-ID: <890b2b0b-59a1-55d1-1914-862fc4a5010b@web.de>
Date: Wed, 20 Nov 2019 00:13:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Rt/oDigGRcgHvMv5OUX6hhrng9G8M4TEsNv61PLcZ5vt+jxz36G ZUewrfqvQKVTsOpamHj8ShFmr20LKU7J19kCm9lMoJxP3Xvbis9jXJ35WaPKDVe+8bG0QRP 9WolfeRWHGSVOCCNJSDdPgLD3wevE43RSJ23RjkWHztLBB0N7WtvIQZxNebMiNTKlrajJQU L0neqf/XN1XvAqZa506gQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:3AirA69r2hI=:mtESSy6CLT8uE+bpnyUY7p 0/jYwfiTr8bZ8seBpSv82fqzowy59AxVT1GowuEdHjq31F+Uh8tQQY2CQA5Lc3bGEXm1WEDhQ DmQGoIrk0lLv73M62U4vkhRaq50Sh+og/RZewEnUHD6+Hevb55ojEbyElXzocI327psDCtL0Y bclDn92/9mOsyfGMf7T7YDkD2MWP2YPpOB7p7V4MHYlBi0F59n4bx7sJ1aaH1PZs26SDwp5R1 Q5MJJ8Q7w+IhEpt6CaSnfjnLahleKdorf35T8sKeWXDiT+OmCQACxiPh5GAsWHvvfTg+6JLMh YDS1ywFIxt6opNPyzxRMj0eAzH5OVt6avumI/fnnDOeqR0FjPzPo69CV6FaLCkcxoDJI4MIgl 6c1lQZZa08aPYwQarjNGCglptzeHtypjSl4iRpKdBqfsmgSf8h4yJvI+IgOnqINbhtilg/hTg gwIhq4LKswXi51DkKUXFDQurXlUOADk048YQ0g6IOjdA5Kb887myF2qLUrQQkA8YWhDz/BM8V DHUk+Htb4/tYluOEnCyHTbWlfJyjU2lxGTw///rwR6q4PHczOtMqli1lTrwd9a1MwZZAfx3sQ +OJsUy7n1glmmhCsp44E37WkIBWcbQoeaF15FmtffHhQGQt9rvgIoJuSbcjz0wPrm/8CYjooc cGRRewHiBMlADrFQwEBpPKkjw5uKCGjBUeVuNN0gebO0UECS7FcKRM+4Nu99P/ny8ZJcNq83w wfe5QYm1Lh0FIBS+Di+PQCAzAUL/uDiQeKtEb9De/kOLPpEDQZkhjnm+2YmZSDRPMqyfAkqff MT31W7kx82uM9RCT+Rp0FNVIL9GvdTzWK0xSzYwA37Q67vjKdm2PNzDRTxnJPBEMiByqtOxAG EoNYQVn6BAmPY1CAp0frBBDebX32r3S+wvNAhWns1hHrpMcxFEE8kAHtK9w2Vt7yYIOIbaMUo OcTYDIOdqTTD6Nv/9QAXVO/NAMZs1a0oGDtIklKBPwngJiujlnSxsVjKfC/Q3d1dHck5FuBN5 /NncipMHMn8kfjA1Q3FOfwniX+XYIEd81SEL0XqyHYa8Um/D5/5FOc2orhS4rSoMb+UjfXKFU MXUyQGUtihYkUaTHEthTr/uA5cgFP1xgnREGoCLSd6smXhFqr1KZPBYq9EakkKgP5mEOPlT0b uf7B70doBdgsgwALNyEpN3TEDE/l41pf2CojeikHoIm5MFOFFcA75jjWpjP3u1z7Jm1hMLPzr Mv3RkJLAn0VRg6OkEx8Gv5Gd5kbEQ850zwVy4C+72fThxXlLHBB+l6fgmXWM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/PRGceW-FyXmaJ1oPawovXVZIBw4>
Subject: [Cfrg] Personal feedback regarding the CFRG PAKE selection process
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: Tue, 19 Nov 2019 23:19:03 -0000

Dear CFRG community,

I would like to share with you the following thoughts regarding the
current state of the PAKE selection process.

It is my conviction (as stated before on the list) that none of the
nominated schemes has critical weaknesses. Therefore the task of the
selection of the primitives might be not so easy/obvious.

In my opinion the team involved with the selection process should base
their choice on the primitives which the best potential of being
actually used in real-world settings. It is my conviction that
protecting password-based authentication will be one of the most
important aspects for improving real-world security and privacy.

In the past patent pitfalls did seriously hamper roll-out of the most
secure options. Now, finally that many PAKE patents having expired
(except for PAK which will expire soon) and patent-free and efficient
constant-time mapping algorithms have been developed for all relevant
curves, chances stand better that PAKE technology with its main feature
of establishing roots of trust in a completely de-centralized setting
will become more wide-spread use.

I now still see the following main risks that might hamper such more
wide-spread use:

- The PAKE scheme rollout in real-world applications might be hampered
by fear, uncertainty and doubt against PAKE regarding resilience to
quantum computer attacks. Personally with my background as a physicists
which has graduated and spent years of his life on studying quantum
correlations in solids, I assess the threat of quantum computing based
attacks *not* to be relevant for most applications. However the true
threat of quantum computing might rather be that people are scared away
from using PAKE because of presumably missing resilience and/or missing
quantum-attack mitigations and use inferior designs instead.

- The second most important aspect which might scare away people from
PAKE is, if implementing the PAKE is considered as too costly / resource
consuming / needs too much code size / too much storage space for
password databases / too complex to implement, etc.. This will most
surely not be an issue for powerful devices, but might result in severe
problems for constrained ones. (To give an example, it was not an
accident, IMO, that the for the earliest Bluetooth LE security layer 4.0
the bluetooth SIG did remove all of the asymmetric cryptographic
algorithms that were already in use for the previous Bluetooth
Basic-Rate security profiles. What drove the SIG was a true resource
problem! It took the SIG years to correct this mistake with BLE 4.2 and

- Finally, If there are too many protocols recommended, we might face
inter-operability issues and people might be scared away from using PAKE
because of too many different options to support and an
inter-operability nightmare.

I am truly curious about what will come out. The only thing that I would
like to stress is that in my opinion CFRG should really come up with *at
least one* recommendation for balanced and augmented PAKE. (Recall that
there were people that did stress that the mission of the PAKE selection
process is actuall choosing "zero or more", seemingly with some
inclination to rather choose zero!)

Finally, I would like to thank all of the reviewers and involved people
for the amazing work and commitment for the tedious work of digging
through all of the provided materials.


Björn Haase