Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NSA and IETF: Fairness

blog.cr.yp.to

Post reply on HN
Print view View original

31–40 of 198 posts

Re: NSA and IETF: Fairness

#31

Post by tptacek »

chrismorgan wrote: post #28
throw0101d wrote: post #15

Earlier quoted context omitted.

> 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 s…

> 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 co…

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.

Re: NSA and IETF: Fairness

#32

Post by tptacek »

jauntywundrkind wrote: post #19

Is there anything different about this DJB mailing list brigading than the other brigading he's done? Four days ago: https://news.ycombinator.com/item?id=48760490

By dint of not including a list of non-cryptographer cosigners, this one is prima facie somewhat less cringe.

Re: NSA and IETF: Fairness

#33

Post by g-b-r »

throw0101d wrote: post #15
ekr____ wrote: post #10

Earlier quoted context omitted.

> (2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS. Two more pieces of context here: 1. The IETF allows code point registrations based purely…

> 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 s…

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.

Re: NSA and IETF: Fairness

#34

Post by yardstick »

DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against?

He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems like he’s playing a few steps ahead where he can (yet again) cry foul on the system and cry foul on vote rigging. Despite him being a key instigator. I’ve already seen at least one poster reference a RFC explaining how IETF consensus works and how its not a pure numbers game (5 for and 100 against can still be consensus, depending on the circumstances; the inverse also applies).

What’s his next step if the authors publish as an information RFC? He can’t stop that, right?

Re: NSA and IETF: Fairness

#35

Post by teravor »

tptacek wrote: post #29
teravor wrote: post #24

Earlier quoted context omitted.

> Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC. this is an absurd claim, lattices may be as well studied as elliptic curves, but not the cryptography.

No, it's not an absurd claim. Lattice key establishment goes back into the mid-1990s, and was at one point a serious contender for the alternative-to-RSA/FFDH algorithm that ECC became. Modern LWE lattice KEM is approximately at the same point in its lifecycle (say, compared to original NTRU) as Curve25519 was to ECDH.

the McEliece cryptosystem goes back to the 70s, doesn't mean it's as well studied as RSA. obviously people study popular cryptographic primitives more.

having said that, I would trust McEliece more than Kyber.

Re: NSA and IETF: Fairness

#36

Post by eqvinox »

tptacek wrote: post #30
dhx wrote: post #27

Earlier quoted context omitted.

To extend on this good point-- DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur. For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have the…

He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.

I do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.

That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.

Re: NSA and IETF: Fairness

#37

Post by tptacek »

eqvinox wrote: post #23
ButlerianJihad wrote: post #17

Earlier quoted context omitted.

Sadly, a similar myth/fallacy persists about the Wikipedia consensus process (at least the English project and others deriving policy from it.) Participants in disputes and RFCs literally call their comments “!vote” in true hacker notation, to repeatedly and clearly emphasize that “vote count” is never a factor in the process of establishing consensus. (Elections are, however, regularly held, and votes counted, for p…

From the way DJB talks about IETF processes, it's quite clear to me though that he has little trust/belief in the IETF consensus process. I thought he said as much somewhere but can't find that right now. (It's particularly obvious in https://blog.cr.yp.to/20260405-votes.html ) Which is why I'm noting the alienation of "IETF believers", which I should maybe clarify I count myself as. The IETF is a lot of people doing…

He famously doesn't support the IETF. In the long-long-long ago, back when I had a "home page" with my username and a tilde in it, I used to have a quote from him on it about the IETF and "ego standards". He's been picking fights like this with different IETF working groups for basically his entire career. This isn't even the first time he's picked a huge fight with IETF cryptography groups; he managed to get Kenny Paterson to publicly take him to task on the CFRG a few years back.

I, too, don't support the IETF (hence the quote on the web page, which I can't find now). But I happen to know enough about the people involved in this particular drama that I can see through his arguments here, and whether he realizes it or not, he's operating in supremely bad faith this time.

Re: NSA and IETF: Fairness

#38

Post by g-b-r »

tptacek wrote: post #31
chrismorgan wrote: post #28

Earlier quoted context omitted.

> 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 co…

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.

If it's documented it will be implemented by many more libraries and applications, that's the argument

Re: NSA and IETF: Fairness

#39

Post by tptacek »

iririririr wrote: post #20

if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.

This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is much more mysterious and spooky than they think it is.

(I'm only somewhat cryptography-literate and so I would myself default to a hybrid, though that opinion might change the first time I bother banging together an MLKEM implementation.)

Re: NSA and IETF: Fairness

#40

Post by g-b-r »

tptacek wrote: post #30
dhx wrote: post #27

Earlier quoted context omitted.

To extend on this good point-- DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur. For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have the…

He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.

"two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023"

Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.

Post reply on HN