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

51–60 of 198 posts

Re: NSA and IETF: Fairness

#51

Post by eqvinox »

tptacek wrote: post #44
eqvinox wrote: post #36

Earlier quoted context omitted.

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

The problem here is that for too many people, Bernstein is one of two living cryptographers with name recognition.

Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.

Re: NSA and IETF: Fairness

#52

Post by ekr____ »

yardstick wrote: post #34

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…

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

This is a slightly complicated question. There are several main routes to an Informational RFC.

* Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the latter is likely to happen if TLS WG decides not to publish. If the TLS WG does decide to publish, then there are a number of steps afterward (AD review, IETF Last Call, IESG Review), plus potential avenues for appeal at some of these stages.

* Through the Independent Submissions Editor (ISE) (though in another comment wbl says that the ISE is not going to publish cryptography standards https://news.ycombinator.com/item?id=48812844). This is essentially at the sole discretion of the ISE and can't be appealed.

In either case, if the document makes it through all these gates and is eventually published as an RFC, then that's pretty much it, as RFCs aren't changed once published.

Re: NSA and IETF: Fairness

#53

Post by ekr____ »

eqvinox wrote: post #47
yardstick wrote: post #34

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…

> …information RFC? He can’t stop that, right? Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".

This document actually is being advanced as Informational, though there are also non-IETF Informational RFCs (see upthread).

Re: NSA and IETF: Fairness

#54

Post by tptacek »

g-b-r wrote: post #49
tptacek wrote: post #43

Earlier quoted context omitted.

Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.

We do all have ECC in our cryptosystems right now, and given how long it's been there, we can rely on its security much more than something new.

So clearly when I go look back at the archives of Bernstein discussing 25519, I'm going to see him advocating for FFDH/25519 cascades, right?

(If my subtext wasn't clear, by the way: the implementation history of ECC is godawful.)

Re: NSA and IETF: Fairness

#55

Post by tptacek »

eqvinox wrote: post #51
tptacek wrote: post #44

Earlier quoted context omitted.

The problem here is that for too many people, Bernstein is one of two living cryptographers with name recognition.

Ah I see what you were trying to say. It read to me (with " He's a cryptographer. You're describing cryptographers. ") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be giv…

Even the side channel stuff in particular --- Bernstein was certainly a popularizer of it, but that's been mainstream in cryptography research since the mid-2000s (and, obviously, it's Paul Kocher's claim to immortality).

One very big problem I have with Bernstein's recent activism is the way he writes to an audience you can just very clearly tell he thinks little of. He's assuming everybody who pays attention to this stuff has paid basically no attention at all to any cryptography he himself didn't write about. It's a bad argument, but that's not my big issue; my big issue is that he's making fools of his supporters. Not OK.

Re: NSA and IETF: Fairness

#56

Post by eqvinox »

tptacek wrote: post #48
eqvinox wrote: post #45

Earlier quoted context omitted.

> whether he realizes it or not, he's operating in supremely bad faith this time. I've met him in person, once, at a CCC event about a decade ago, and as someone clueless about cryptography all I can say to that is that he certainly had (has?) a my-way-or-the-highway personality. > I, too, don't support the IETF Out of curiosity, how would you maintain e.g. TLS? Something more academic? Raw "throw it all out there, b…

For the record, he's always been extremely nice to me, online and in person, and generous with his time. I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.

> I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.

Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations. Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification? (searches - ah, yes, it does. I do know there have been a very number of "further" implementations [e.g. on FreeBSD], though I'm not sure if they're derivative or clean-room.)

But then isn't this just replacing IETF processes with whatever community or corporate processes those projects have? Wouldn't that just be "get shit into {the Linux kernel,OpenBSD}"? They've gotten better but both of those communities have their shortcomings. (For Linux, it's not the social interactions anymore, at this point it's the significant corporate interests.)

Re: NSA and IETF: Fairness

#57

Post by g-b-r »

maqp wrote: post #26
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.

Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.

> is going around the encryption by hacking endpoints

Because they weren't (supposedly) able to break the encryption

> than to attack the algorithms

You have an opportunity to introduce new, broken, algorithms; they exploited it with DES, tried to exploit it with ECC, why wouldn't they try it with post-quantum (which they've kind of been pushing)?

Re: NSA and IETF: Fairness

#58

Post by chrismorgan »

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.

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.)

Re: NSA and IETF: Fairness

#59

Post by tptacek »

eqvinox wrote: post #56
tptacek wrote: post #48

Earlier quoted context omitted.

For the record, he's always been extremely nice to me, online and in person, and generous with his time. I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.

> I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies. Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations . Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification…

WireGuard in particular is both an implementation and a design, and the design effectively belongs to Jason Donenfeld.

The problem with cryptographic standards bodies is that committee-based design has a long track record of weakening protocols. Originally, part of the ethos of the IETF was that it was merely providing interop for things that were already happening; rough consensus around real implementations. But that attitude expired decades ago; things are now designed de novo in working groups.

Through a herculean effort, TLS-WG managed through that fucked process to drastically improve TLS in 1.3. It did that in part because a team of cryptographers and cryptography engineers camped on the working group and made sure the outcome was sane. And they nearly failed! Banks fought hard to try to keep static handshakes in the new version, so they could do compliance intercepts.

Unfortunately, fully documenting PQC cryptography isn't as glamorous a task as defining the next generation's version of TLS. And yet, we've got a somewhat diverse team of cryptographers on the working group lined up against Bernstein on this.

Re: NSA and IETF: Fairness

#60

Post by g-b-r »

tptacek wrote: post #54
g-b-r wrote: post #49

Earlier quoted context omitted.

We do all have ECC in our cryptosystems right now, and given how long it's been there, we can rely on its security much more than something new.

So clearly when I go look back at the archives of Bernstein discussing 25519, I'm going to see him advocating for FFDH/25519 cascades, right? (If my subtext wasn't clear, by the way: the implementation history of ECC is godawful.)

Was FFDH considered safe?

> the implementation history of ECC is godawful

You do know that new cryptographic code can be godawful, then?

Post reply on HN