John Preuß Mattsson review of the document

[emanjon]

Hi,

I saw this document mentioned on the SAAG list and made a review. Comments/suggestions below
https://mailarchive.ietf.org/arch/msg/saag/WwcDitxfrT1P2cE3VpT2dLRI3ns/

• "Several Web standards depend on cryptographic primitives to reach security properties such as confidentiality, integrity, authenticity, and non-repudiation."

I suggest also listing availability, which is a fundamental security property and part of the CIA information-security triad. I also don’t think non-repudiation should be mentioned without acknowledging its counterpart, repudiation. Many modern privacy mechanisms explicitly aim for the opposite of non-repudiation, namely providing repudiation/deniability. The same comment apply to other sections of the document.

• "Cryptography" is the practice and study of techniques for securing communication and information by transforming it into a format that is unreadable to unauthorized users.

This reads more like a definition of confidentiality than of cryptography. I would suggest something along the lines of: “Cryptography is the discipline of designing systems that uphold security properties even in the presence of intentional misuse or active attacks.”

• I strongly believe Section 2 should explicitly discuss and discourage the use of paywalled standards. Reliance on paywalled cryptography specifications poses a significant cybersecurity risk. I would also argue that access to cryptographic specifications is a human right. For these reasons, the IETF is actively working to remove all references to paywalled cryptography standards, and the upcoming revision RFC 8446bis will eliminate several such references. The W3C should follow suit. This is also reflected in industry practices: Ericsson, for example, has removed all paywalled cryptography standards from its internal guidelines, viewing them as security risks. With freely available cryptography standards from NIST, IETF, CFRG, ETSI, and others, there is no justification for using paywalled cryptography standards.

• "digital signatures can ensure both authenticity and non-repudiation"

EUF-CMA signatures provide very weak non-repudiation, as the private-key owner can plausibly claim, “I didn’t produce this particular signature.” Hopefully, signatures vulnerable to trivial EUF-CMA attacks will be phased out during the migration to post-quantum cryptography.

• "the key must remain secret."

Would be good to also mention public keys in this section.

• "However, in some cryptographic algorithms longer keys also require more computational resources for encryption and decryption processes."

This sentence would be better and more general without "for encryption and decryption processes"

• OLD: "to break many of the widely used cryptographic algorithms"
  NEW: "to break many of the widely used asymmetric cryptographic algorithms"

See e.g., https://datatracker.ietf.org/liaison/1942/

• Section 6 should be updated to highlight that NIST/CFRG have already standardized five post-quantum cryptography algorithms: ML-KEM, ML-DSA, SLH-DSA, LMS, and XMSS.

• Section 7.1 on symmetric encryption appears outdated. It overemphasizes IND-CPA encryption, which offers no security against active attackers and should only be used in very limited scenarios. I do not think AES-CTR with HMAC should be recommended in general; instead, AEAD algorithms such as AES-GCM or ChaCha20-Poly1305 should be the recommended choices.

• Authenticated encryption is also essential for providing confidentiality against active attackers—something that IND-CPA algorithms alone cannot guarantee.

• "The most recommended key wrapping algorithm is AES-KW"

I think AES-KWP should be recommended over AES-KW. A limitation with NIST-SP-800-38F is that only 64-bit tags are supported. Hopefully this will be addressed when NIST standardized accordions.

• "Although KW can be used in conjunction with any reversible padding scheme"

People should not be encouraged to invent their own padding schemes for any cryptographic algorithms.

• "The most recommended mode for encrypting data on storage devices is XTS-AES"

While XTS-AES is the most widely used mode for file system encryption, I do not believe it should be recommended. Adiantum, supported since Linux kernel 5.0, is a superior choice: it can encrypt entire 4 KiB sectors as a single block, whereas XTS-AES operates on 128-bit blocks and suffers from “ECB-penguin” patterns across time. It should also be noted that XTS-AES and Adiantum are suitable only for scenarios such as file system encryption where AEAD cannot be used. For individual file encryption, there are far better alternatives, such as age, which uses AEAD.

• It is important to note that keys with 256 bits length are considered secure against brute-force attacks even in a post-quantum scenario.

I would remove this. Keys with 128 bits length is also considered secure against brute-force attacks. In fact, NIST defines quantum security category I as equal to AES-128. If W3C recommends AES-256 because of quantum-resistance (i.e., category 5), you should also recommend ML-KEM-1024, which would mean that X25519MLKEM768 is not recommended.
See e.g.,
https://datatracker.ietf.org/liaison/1942/
https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_118_Hyderabad/docs/S3-244307.zip

• I think section 7.2 should be rewritten to talk about and recommend hybrid encryption such as HPKE (RFC 9180). I think you should talk about HPKE as "asymmetric encryption". Non-hybrid asymmetric encryption is only practically relevant for encrypting a CEK.

• "New applications are required to use RSAES-OAEP"

This seems very weird. RSA should not be recommended at all. Old systems should use ECIES such as HPKE and new systems should use HPKE with ML-KEM. I very much agree with Sophie Smieg that "I would say that my trust in lattice cryptography is pretty much equal to my trust in elliptic curves, and quite a bit higher than my trust in RSA"
https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

• OLD: "and HQC"
  NEW: "and HQC-KEM"

• "the most widely used and recommended curves are the NIST curves"

Unclear if they are the most widely used. X25519 is dominating on the Web. I think Curve2559 and Curve44 should be recommended over the NIST curves for new systems.

• "Falcon"

I think all mentions of Falcon should be changed to FN-DSA. The pre-standardized Falcon should not be used.

• "but also in TLS and SSH"

If anybody is using secp256k1 in TLS and SSH, I think the usage is so small that it is not worth mentioning. The curves standadized by SECG should be written without capital S, i.e., secp256r1, not Secp256r1.

• "However, longer tags also require more computational resources for generation and verification processes."

Typically not, they just require more bytes to transmit and store.

• "In general, the recommended tag length for MACs is at least 128 bits to provide adequate security against brute-force attacks, while 256 bits tag length provides a higher level of security for applications that require stronger protection."

I have a hard time imagining any reason to ever recommend more than a 128-bit MAC.

• the recommended tag length is at least 160 bits when using SHA-1

I think the recommendation should be to not use SHA-1

• "In general, MACs with 64 bits tag length are considered weak and not recommended for secure applications."

Note this recommendation goes against the earlier recommendation to use AES-KW(P) which has 64-bit tags. I have never heard of any practical attacks that use 64-bit tags so I think AES-KW(P) is fine.

• The source key is often referred to as the "master key"

IETF tries to stop using the word "master" altogether.

• "They are designed to be computationally intensive and resistant to brute-force attacks"
  "strong security guarantees against various types of attacks"

No, most PBKDFs are absolutely not resistant to brute-force attacks, they just make brute-force attacks slightly harder. The security level of AES-256-GCM with a PBKDFs derived key from a human generated password is still on average weaker than single-DES. If your password database is leaked you must assume that the attacker will recover all the passwords. This is the reason passwords alone should never be used for encryption and why NIST is recommending to encrypt the password database with a separate key (sometimes called pepper) stored in a TPM.

[Frosne]

I am curious what's the best way to proceed now. Should we create an issue for each big block you mentioned?

(P.s. I am not the author of the draft, just passing by :D)