4 ms·

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 t

by g-b-r 4mo ago

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.

lokar 4mo ago
But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
- g-b-r 4mo ago
  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).
- ButlerianJihad 4mo ago
  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 4mo ago
    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 https://en.wikipedia.org/wiki/Crypto_Wars
    - mswphd 4mo ago
      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.
    - tptacek 4mo ago
      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.)
- AdamN 4mo ago
  The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.
  - dhx 4mo 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

by g-b-r 4mo ago

lokar 4mo ago

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

g-b-r 4mo ago
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).
ButlerianJihad 4mo ago
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 4mo ago
  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 https://en.wikipedia.org/wiki/Crypto_Wars
  - mswphd 4mo ago
    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.
  - tptacek 4mo ago
    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.)
AdamN 4mo ago
The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.
- dhx 4mo 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