Comment by jcranmer
4 days ago
So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. Now, I'm a passionate supporter of this feature, for various reasons, that I can (and have, in the committee) brought up. And I know some people who are against this feature, for various reasons that have been brought up. And at the end of the day, it kind of is a popularity contest because weighing an argument of "based on my experience, this is going to be confusing for users" versus "based on my experience, this is not going to be confusing for users" is just a popularity contest among the voters on the committee, admittedly weighted by how much you trust the various people.
And then there's a third category of person (really, just one person I think, though). This is responsible for the vast majority of the email traffic on the topic. They're always ready with a detailed point-by-point reply of any replies to their posts. And their argument is... um... they don't like the feature. And they so don't like the feature that they're hanging on to any scintilla of a process argument to make their displeasure derail the entire feature, without really being able to convince anybody else of their dislike (or being able to be convinced to change their mind to any argument).
Now I don't have the cryptographic chops to evaluate DJB's arguments myself. But I also haven't seen any support for his arguments from people I'd trust to be able to evaluate them. And the way he's responding at this point reminds me very much of that third category of people, which is adversely affecting his credibility at this point.
The really big difference between named loops and cryptography is that if one gets approved and is bad, a couple new programmers get confused, while with the other, a significant chunk of the internet becomes vulnerable to hacking.
Just because a feature is standardized does not mean it gets implemented. This is actually even more true for cryptography than it is for programming language specifications.
The situation is actually somewhat the opposite here: the code points for these algorithms have already been assigned (go to https://www.iana.org/assignments/tls-parameters/tls-paramete... and search for draft-connolly-tls-mlkem-key-agreement-05) and Chrome, at least, has it implemented behind a flag (https://mailarchive.ietf.org/arch/msg/tls/_fCHTJifii3ycIJIDw...).
The question at hand is whether the IETF will publish an Informational (i.e., non-standard) document defining pure-MLKEM in TLS or whether people will have to read the Internet-Draft currently associated with the code point.
> Just because a feature is standardized does not mean it gets implemented.
This makes no sense. If you think it actually had a high chance of remaining unimplemented it anyway then why not just concede the point and take it out? It sure looks like you're not fine with leaving it unimplemented, and you're doing this because you want it implemented, no? It makes no sense to die on that hill if you're gonna tell people it might not exist.
Also, how do you just completely ignore the fact that standards have been weakened in the past precisely to achieve their implementation? This isn't a hypothetical he's worried about, it has literally happened. You're just claiming it's false despite history blatantly showing the opposite because... why? Because trust me bro?
> So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. (...it) is just a popularity contest
Thankfully cryptography design isn't programming language design, what we have here neither is nor should be a debate or contest over popularity, and the costs of being wrong are enormously different between the two, so you can just sleep easy knowing that your experience doesn't extrapolate to the situation at hand.
I marvel at your ability to consider cryptographers as inhuman machines, despite evidence to the contrary.