[Cfrg] Personal feedback regarding the CFRG PAKE selection process

[Björn Haase <[e-mail]>]

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
later.)

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

Yours,

Björn Haase