PBKDF2 requirement R.1.1 unfit for 5.1 Master Password Authentication purpose

Vertical Standard Comment

Please complete the below fields. Further instructions can be found in the repositories README.md Do not forget to add a Label, using the sidebar on the right.

Standard Version (see README.md for info): 25d63ae5

Line Number: #L1685

Clause/Subclause: 5 Password Manager Security Requirements / 5.1 Master Password Authentication

Paragraph/Figure/Table: Requirement R1.1

Comment: Cryptology has been accelerating exponentially during our lifetime so referring to PBKDF2 as "a kludge from more than a quarter of a century ago for people who do not know better (1999 bcrypt, 2009 scrypt, 2015 Argon2)" might not even be enough of a wake-up call to carry across how harmful it would be for ETSI to require it as the core of Password Manager Security.

Proposed Changes:

R1.1: SHALL implement purpose-built password protection as per the current state of the art, which at some point may for example involve a Bandwidth Hard Function (BHF) to defend from attackers armed with ASICs and/or FPGAs but at the time of this writing means a Memory Hard Function (MHF) to at least try to level the playing field between the legitimate user running on CPU and any teenage hacker with orders of magnitude more hashing power in the GPU of a typical gaming PC, not to mention serious attackers with GPU farms; Argon2 is the current MHF best practice, scrypt is second best. Whether bcrypt can still be considered good practice is debatable since it is neither a MHF nor a BHF so it should be considered with much lower priority, but since it was designed as a "slow hash" specifically for the purpose of password protection it should still be considered long before giving PBKDF2 any thought. If all else fails and only then, should a Key Derivation Function (KDF) be used even if its name says it is Password-Based: "fast hashes" such as SHA-2, SHA-3 and so on are amazing algorithms for many purposes, just not for password protection so PBKDF2's looping of a fast hash will always be an ugly hack regardless of whether you do it for 100k, 600k or even more iterations. In case a boat analogy helps: MHFs/BHFs are like propellers/impellers underwater for best performance, bcrypt is like the huge fan of an airboat i.e. suboptimal but ok if underwater was impossible, and PBKDF2 is like wondering how fast a hairdryer fan should spin to be usable as airboat propulsion.