3 ms·

The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.

by AdamN 3mo ago

dhx 3mo ago
To point out some positive examples of what RFCs should include: RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1] RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2] By contrast, this proposed RFC for MLKEM provides a single encouragement: "[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3] It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC. When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself: "Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4] The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation. The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon? The key missing section of this RFC is perhaps a restriction on its application similar to: "This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol." Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls. [1] https://datatracker.ietf.org/doc/html/rfc5288#section-3 https://datatracker.ietf.org/doc/html/rfc5288#section-3 [2] https://datatracker.ietf.org/doc/html/rfc7748#section-5 https://datatracker.ietf.org/doc/html/rfc7748#section-5 [3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ [4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... [5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
- tptacek 3mo ago
  You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're looking for to other RFCs.
  - dhx 3mo ago
    From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1] But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance. The draft MLKEM IKEv2 RFC[2] has the same problem. Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive: Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret." To include side channel resistance, for example: Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values." Some further examples of RFCs which do care about specifying side channel resistance: RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3] RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4] (this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance) [1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4 https://www.rfc-editor.org/info/rfc8446/#appendix-E.4 [2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml... [3] https://www.rfc-editor.org/info/rfc9980/#section-9.3 https://www.rfc-editor.org/info/rfc9980/#section-9.3 [4] https://www.rfc-editor.org/info/rfc9941/#section-4 https://www.rfc-editor.org/info/rfc9941/#section-4
mswphd 3mo ago
using pure ML-KEM is not a footgun. Some people may have doubts about lattice-based cryptography, despite being securely deployed in Chrome nearly a decade ago. Some people have doubts about many things. The fact that people have doubts does not make the scheme a "footgun".
- tptacek 3mo ago
  It is if literally the only thing you've ever read about the technical details of LWE cryptography is Daniel Bernstein.
  - mswphd 3mo ago
    you'd probably call it "Product NTRU" then, and be a minimum a decade out of date. So you'd probably have to do all that weird shit with co-different ideals Peikert was trying to get us all to do (I know it was "right" but sometimes you need to put a muzzle on the math guys for all of our sakes).

The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.

by AdamN 3mo ago

The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.

dhx 3mo ago

To point out some positive examples of what RFCs should include: RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1] RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2] By contrast, this proposed RFC for MLKEM provides a single encouragement: "[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3] It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC. When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself: "Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4] The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation. The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon? The key missing section of this RFC is perhaps a restriction on its application similar to: "This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol." Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls. [1] https://datatracker.ietf.org/doc/html/rfc5288#section-3 https://datatracker.ietf.org/doc/html/rfc5288#section-3 [2] https://datatracker.ietf.org/doc/html/rfc7748#section-5 https://datatracker.ietf.org/doc/html/rfc7748#section-5 [3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ [4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... [5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

tptacek 3mo ago
You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're looking for to other RFCs.
- dhx 3mo ago
  From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1] But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance. The draft MLKEM IKEv2 RFC[2] has the same problem. Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive: Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret." To include side channel resistance, for example: Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values." Some further examples of RFCs which do care about specifying side channel resistance: RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3] RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4] (this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance) [1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4 https://www.rfc-editor.org/info/rfc8446/#appendix-E.4 [2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml... [3] https://www.rfc-editor.org/info/rfc9980/#section-9.3 https://www.rfc-editor.org/info/rfc9980/#section-9.3 [4] https://www.rfc-editor.org/info/rfc9941/#section-4 https://www.rfc-editor.org/info/rfc9941/#section-4

mswphd 3mo ago

using pure ML-KEM is not a footgun. Some people may have doubts about lattice-based cryptography, despite being securely deployed in Chrome nearly a decade ago. Some people have doubts about many things. The fact that people have doubts does not make the scheme a "footgun".

tptacek 3mo ago
It is if literally the only thing you've ever read about the technical details of LWE cryptography is Daniel Bernstein.
- mswphd 3mo ago
  you'd probably call it "Product NTRU" then, and be a minimum a decade out of date. So you'd probably have to do all that weird shit with co-different ideals Peikert was trying to get us all to do (I know it was "right" but sometimes you need to put a muzzle on the math guys for all of our sakes).