3 ms·

> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete... Further

> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete... Further the draft that this is all about does not make a recommendation for its use. The currently IETF-recommended TLS algorithms are: X25519MLKEM768, x448, x25519, secp384r1, secp256r1. As noted by someone on the IETF list [1] there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document. No one is forcing anyone to use this algorithm, and it's not even 'officially' recommended (per above). [1] https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

chrismorgan 3mo ago
> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. (There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.) This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.
- tptacek 3mo ago
  These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.
  - g-b-r 3mo ago
    If it's documented it will be implemented by many more libraries and applications, that's the argument
    - tptacek 3mo ago
      It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.
      - g-b-r 3mo ago
        Can you (or someone else) please give some example of those environments?
        some_furry 3mo ago
        Telecoms. I wrote at length about this debate in my blog post about threat modeling: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/ https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...
  - chrismorgan 3mo ago
    I know approximately nothing about the specific case here, and don’t believe I have any skin in the game. I intended my comment purely abstractly: I’m not commenting on anything technical, merely mentioning a procedural concern: that the line I quoted can sound reasonable, but that I don’t think it’s actually a reasonable argument by itself, because of the likely consequences of such actions. (That is: if that happened to be the only argument—though I doubt it is—there’s a compelling case for rejecting it.)
  - rasengan 3mo ago
    [flagged]
- throw0101d 3mo ago
  > “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. The GOST cipher, which is Russia's AES equivalent, is also in an RFC: * https://datatracker.ietf.org/doc/html/rfc9189 https://datatracker.ietf.org/doc/html/rfc9189 * https://en.wikipedia.org/wiki/GOST_(block_cipher) https://en.wikipedia.org/wiki/GOST_(block_cipher) Is the IETF validating its use? The GOST document is categorized in the same way as the one currently being debated/discussed: Informational. It also has "N" under the "Recommended" column (like ML-KEM-only will have): * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete...
  - ekr____ 3mo ago
    In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792 https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind. * Through the IETF * Through the Independent Stream The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish. I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..
    - throw0101d 3mo ago
      I have gotten flack for giving ULA+NPTv6 as a possible solution to an IPv6 multi-homing issue because the RFC that describes it was 'only' "Experimental": * https://datatracker.ietf.org/doc/html/rfc6296 https://datatracker.ietf.org/doc/html/rfc6296 When I pointed out that the NAT(44) RFC (1631/3022) was 'only' "Informational" I got radio silence: * https://datatracker.ietf.org/doc/html/rfc1631 https://datatracker.ietf.org/doc/html/rfc1631
g-b-r 3mo 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 3mo ago
  But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
  - g-b-r 3mo 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 3mo 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 3mo 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

chrismorgan 3mo ago

> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. (There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.) This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.

tptacek 3mo ago
These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.
- g-b-r 3mo ago
  If it's documented it will be implemented by many more libraries and applications, that's the argument
  - tptacek 3mo ago
    It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.
    - g-b-r 3mo ago
      Can you (or someone else) please give some example of those environments?
      - some_furry 3mo ago
        Telecoms. I wrote at length about this debate in my blog post about threat modeling: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/ https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...
- chrismorgan 3mo ago
  I know approximately nothing about the specific case here, and don’t believe I have any skin in the game. I intended my comment purely abstractly: I’m not commenting on anything technical, merely mentioning a procedural concern: that the line I quoted can sound reasonable, but that I don’t think it’s actually a reasonable argument by itself, because of the likely consequences of such actions. (That is: if that happened to be the only argument—though I doubt it is—there’s a compelling case for rejecting it.)
- rasengan 3mo ago
  [flagged]
throw0101d 3mo ago
> “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. The GOST cipher, which is Russia's AES equivalent, is also in an RFC: * https://datatracker.ietf.org/doc/html/rfc9189 https://datatracker.ietf.org/doc/html/rfc9189 * https://en.wikipedia.org/wiki/GOST_(block_cipher) https://en.wikipedia.org/wiki/GOST_(block_cipher) Is the IETF validating its use? The GOST document is categorized in the same way as the one currently being debated/discussed: Informational. It also has "N" under the "Recommended" column (like ML-KEM-only will have): * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete...
- ekr____ 3mo ago
  In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792 https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind. * Through the IETF * Through the Independent Stream The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish. I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..
  - throw0101d 3mo ago
    I have gotten flack for giving ULA+NPTv6 as a possible solution to an IPv6 multi-homing issue because the RFC that describes it was 'only' "Experimental": * https://datatracker.ietf.org/doc/html/rfc6296 https://datatracker.ietf.org/doc/html/rfc6296 When I pointed out that the NAT(44) RFC (1631/3022) was 'only' "Informational" I got radio silence: * https://datatracker.ietf.org/doc/html/rfc1631 https://datatracker.ietf.org/doc/html/rfc1631

g-b-r 3mo 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 3mo ago
But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
- g-b-r 3mo 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 3mo 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 3mo 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