If it's supported it will be used, e.g. by vendors which decide for some reason to use it

Null encryption used to be supported as well, and no one was forced to use it.

But when something insecure is supported by a protocol it will lead to security hiccups.

If it's dangerous it shouldn't be supported.

But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.

▲

ButlerianJihad a day ago | parent | next [-]

Heh heh heh.

I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered.

I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DARPA, after all) but Internet protocols were so ridiculously insecure, and based on absurd trust models that were repeatedly broken, and everything always transmitted in plaintext (because, of course, all networks were physically wired, secured, and only the good guys could tap into them).

It was an absolute Wild West clown college as the Internet transitioned to commercial and privatized use cases, and I suppose it guaranteed job security for generations of cybersecurity experts and cryptographers.

▲

leonidasrup 21 hours ago | parent [-]

In the 90s, you as a private person were not supposed to have access to encyption which could not be broken by NSA.

"The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the key in the SSL protocol."

https://en.wikipedia.org/wiki/Crypto_Wars

	▲	tptacek 19 hours ago \| parent \| next [-]
		No. In the 1990s, you weren't allowed to export cryptography the NSA couldn't break. Strong cryptography was widely available in the 1990s. (I had the pleasure of shipping a commercial product, back in the days when those things shipped in shrink-wrapped boxes, that carried strong cryptography, and had to deal with the export regime. It was not fun.)
	▲	mswphd 20 hours ago \| parent \| prev [-]
		note that this says something more limited than what you're saying. Specifically, an american company was not allowed to give access to the cryptography you describe to non-Americans. This was still a very bad policy, but private americans were allowed to have strong cryptography.

▲

g-b-r a day ago | parent | prev | next [-]

They publish what become standards, you can't just support any existing option in an encryption protocol (if you want to have a secure one).

▲

AdamN a day ago | parent | prev [-]

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

▲

mswphd 20 hours ago | parent | next [-]

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 19 hours ago | parent [-]

It is if literally the only thing you've ever read about the technical details of LWE cryptography is Daniel Bernstein.

	▲	mswphd 17 hours ago \| parent [-]
		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).

▲

dhx a day ago | parent | prev [-]

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

[2] https://datatracker.ietf.org/doc/html/rfc7748#section-5

[3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

▲

tptacek 19 hours ago | parent [-]

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 9 hours ago | parent [-]

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

[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml...

[3] https://www.rfc-editor.org/info/rfc9980/#section-9.3

[4] https://www.rfc-editor.org/info/rfc9941/#section-4

▲

tptacek 8 hours ago | parent [-]

Sir, this is a Wendy's. You're giving me a phone book's worth of RFC cites here but not a lot of indication that you spend a lot of time reading RFCs generally. The RFC we're discussing on this thread is an ancillary publication documenting code points for a specific configuration of MLKEM, which is already extensively documented in other RFCs. Ancillary RFCs like these are for obvious reasons brief.

	▲	dhx 5 hours ago \| parent [-]
		My key point you are avoiding with personal attacks is: If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)? -- The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort to be side channel resistant. The end state for MLKEM-only will be the IANA registry stating TLS named group 0x200 (MLKEM512) is specified in RFCxxxx (draft-ietf-tls-mlkem), and this RFC will refer to FIPS 203 for cryptographic primitives. At no time is side channel resistance in any way guaranteed by either draft-ietf-tls-mlkem or FIPS 203. The situation for TLS named group 0x0029 (x25519) is different. The IANA registry nominates RFC 8446 as the relevant specification.[1] And RFC 8446 nominates a specification (RFC 7748) which does require implementation of cswap as a measure of side channel resistance.[2][3] So when you trace through the specifications starting from the IANA registry, it is unambiguous that TLS named group 0x0029 should provide at least some degree of side channel resistance. Even for this case, I'd argue the SHOULD would be better as a MUST (with possibility to add another TLS named group specifically for x25519-unsafe without constant-time cswap if anyone cares for it). And I'd also argue that RFC 8446/TLSv1.3 should require (not just suggest or hope) that implementations MUST only use constant time functions when processing ECDHE parameters per s4.2.8.2.[2] TSLv1.3 already requires AEAD use elsewhere to force constant-time processing. It's worth noting TLSv1.3 currently doesn't provide any guarantee about side channel resistance of secp256r1, secp384r1, and secp521r1. TLSv1.3 currently just provides this guarantee for X25519 and X448. [1] https://www.iana.org/assignments/tls-parameters/tls-paramete... [2] https://www.rfc-editor.org/info/rfc8446/#section-4.2.8.2 [3] https://www.rfc-editor.org/info/rfc7748/#section-5