7 ms·

> I'm happy to report that 82 people spoke up on the TLS mailing list in unambiguous opposition to this spec during the voting period How many of them spoke be

> I'm happy to report that 82 people spoke up on the TLS mailing list in unambiguous opposition to this spec during the voting period How many of them spoke before on this mailing list, in any capacity what so ever? I suspect this is 99% people who showed up because you organized a brigadging, because you incited people and told them to show up and be completely outraged. There's a >0% chance that DJB could be correct that there is some risk to this spec (which notably is not seeking recommendation status! So WTF?) The people approving and wanting this aren't fools, aren't lackies, aren't some great foe. There's little real opposition? Making up ghosts and enemies lurking in every corner, brigading people to show up in IETF meetings, who have never participated before, just to spread heat and anger you've programmed them for, is ignoble & indecent. All too recently: https://news.ycombinator.com/item?id=48760490 https://news.ycombinator.com/item?id=48760490 https://news.ycombinator.com/item?id=48811887 https://news.ycombinator.com/item?id=48811887

cornstalks 2mo ago
> which notably is not seeking recommendation status! I don’t have a dog in this fight, but some extremely important RFCs are only on the “informational” track. RFCs 1945 (HTTP 1.0), 4627 (JSON), 2818 (HTTPS), etc.
- tptacek 2mo ago
  HTTP, JSON, and HTTPS all have standards-track RFCs.
  - cornstalks 2mo ago
    As far as I know HTTP 1.0 doesn't have a standards-track RFC (HTTP 1.1 and later do). JSON and HTTPS do indeed have standards-track RFCs, but I stand by my original wording that their first informational RFCs were "extremely important."
cassonmars 2mo ago
because the NSA has never surreptitiously pushed bad standards they used to exploit before /s
- tptacek 2mo ago
  Which PQC standard are you suggesting they pushed, and how did they push it? Flesh the argument out.
  - vlovich123 2mo ago
    That’s a very unfair position to take when dealing with secret agencies who try very hard to obfuscate this stuff - it is hard to provide evidence for in the moment. The government has intentionally acted to weaken DES, standardized Dual_EC_DRBG, performed subtle subterfuge through interfering how NIST operates to inject weaknesses and vulnerabilities, trying to weaken SSL and IPSec, 4G smartphone encryption. These are all documented examples of the NSA engaging in bad faith. So whether or not it is happening in this particular case, there’s now just zero trust in the institutions acting in good faith. And given it took decades for the actions to come out after they were taken, how do you expect someone to answer your request to present evidence there’s anything nefarious happening now? Anyway, that’s what I think a fleshed out argument would look like
    - tptacek 2mo ago
      It's a simple question. I'm not asking anybody to prove anything. I'm literally asking: propose the PQC standard IETF could have subverted, and give a sketch of how they could have done it. The bar is merely "plausibility". I'm not asking whether NSA has subverted standards before; obviously they have. NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since.
      - Vecr 2mo ago
        > NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since That's why you use ML-KEM 1024 at all... As part of a hybrid.

cornstalks 2mo ago

> which notably is not seeking recommendation status! I don’t have a dog in this fight, but some extremely important RFCs are only on the “informational” track. RFCs 1945 (HTTP 1.0), 4627 (JSON), 2818 (HTTPS), etc.

tptacek 2mo ago
HTTP, JSON, and HTTPS all have standards-track RFCs.
- cornstalks 2mo ago
  As far as I know HTTP 1.0 doesn't have a standards-track RFC (HTTP 1.1 and later do). JSON and HTTPS do indeed have standards-track RFCs, but I stand by my original wording that their first informational RFCs were "extremely important."

cassonmars 2mo ago

because the NSA has never surreptitiously pushed bad standards they used to exploit before /s

tptacek 2mo ago
Which PQC standard are you suggesting they pushed, and how did they push it? Flesh the argument out.
- vlovich123 2mo ago
  That’s a very unfair position to take when dealing with secret agencies who try very hard to obfuscate this stuff - it is hard to provide evidence for in the moment. The government has intentionally acted to weaken DES, standardized Dual_EC_DRBG, performed subtle subterfuge through interfering how NIST operates to inject weaknesses and vulnerabilities, trying to weaken SSL and IPSec, 4G smartphone encryption. These are all documented examples of the NSA engaging in bad faith. So whether or not it is happening in this particular case, there’s now just zero trust in the institutions acting in good faith. And given it took decades for the actions to come out after they were taken, how do you expect someone to answer your request to present evidence there’s anything nefarious happening now? Anyway, that’s what I think a fleshed out argument would look like
  - tptacek 2mo ago
    It's a simple question. I'm not asking anybody to prove anything. I'm literally asking: propose the PQC standard IETF could have subverted, and give a sketch of how they could have done it. The bar is merely "plausibility". I'm not asking whether NSA has subverted standards before; obviously they have. NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since.
    - Vecr 2mo ago
      > NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since That's why you use ML-KEM 1024 at all... As part of a hybrid.