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

NSA and IETF, part 3: Dodging the issues at hand

blog.cr.yp.to

Post reply on HN
Print view View original

71–80 of 249 posts

Re: NSA and IETF, part 3: Dodging the issues at hand

#71

Post by [deleted] »

HelloNurse wrote: post #36
zahllos wrote: post #24

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal…

The metaphor near the beginning of the article is a good summary: standardizing cars with seatbelts, but also cars without seatbelts. Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible: IETF standardization is a great opportunity for a long term social engineering operation, much like DES, Clipper, the more recent funny elliptic curve,…

[deleted]

Re: NSA and IETF, part 3: Dodging the issues at hand

#72

Post by dataflow »

pverheggen wrote: post #63

While it's true that six others unequivocally opposed adoption, we don't know how many of those oppose the chairs claiming they have consensus. This may be a normal ratio to move forward with adoption, you'd have to look at past IETF proceeding to get a sense for that. One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write…

> One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write lengthly responses that question people's motives, like in this blog post and others.

I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? Why all the lies and distortions otherwise - how does one assume a generous explanation for lies and distortions?

Re: NSA and IETF, part 3: Dodging the issues at hand

#73

Post by crote »

jcranmer wrote: post #20
abhv wrote: post #14

20+2 (conditional support) versus 7. 22/29 = 76% in some form of "yea" That feels like "rough consensus"

The standard used in the C and C++ committees is essentially a 2-to-1 majority in favor. I'm not aware of any committee where a 3-to-1 majority is insufficient to get an item to pass. DJB's argument that this isn't good enough would, by itself, be enough for me to route his objections to /dev/null; it's so tedious and snipey that it sours the quality of his other arguments by mere association. And overall, it gives t…

Standards - especially security-critical ones - shouldn't be a simple popularity contest.

DJB provided lengthy, well-reasoned, and well-sourced arguments against adoption with his "nay" vote. The "aye" votes didn't make a meaningful counter-argument - in most cases they didn't even bother to make any argument at all and merely expressed support.

This means there are clearly unresolved technical issues left - and not just the regular bikeshedding ones. If he'd been the only "nay" vote it might've been something which could be ignored as a mad hatter - but he wasn't. Six other people agreed with him.

Considering the potential conflict of interest, the most prudent approach would be to route the unsubstantiated aye-votes to /dev/null: if you can't explain your vote, how can we be sure your vote hasn't been bought?

Re: NSA and IETF, part 3: Dodging the issues at hand

#74

Post by zahllos »

blintz wrote: post #70
HelloNurse wrote: post #36

Earlier quoted context omitted.

The metaphor near the beginning of the article is a good summary: standardizing cars with seatbelts, but also cars without seatbelts. Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible: IETF standardization is a great opportunity for a long term social engineering operation, much like DES, Clipper, the more recent funny elliptic curve,…

> Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.

SHA-2 was designed by the NSA. Nobody is saying there is a backdoor.

Re: NSA and IETF, part 3: Dodging the issues at hand

#75

Post by dataflow »

blintz wrote: post #64

Standardizing a codepoint for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. You can see him do this on the mailing list: https://mailarchive.ietf.org/arch/browse/tls/?q=djb

> standardizing a code point (literally a number) for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it.

I think the whole point is that some people would be forced to use it due to other standards picking previously-standardized ciphers. He explains and cites examples of this in the past.

> He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous.

He comes with historical and procedural evidence of bad faith. Why is this ridiculous? If you see half the submitted ciphers being broken, and lies and distortions being used to shove the others through, and historical evidence of the NSA using standards as a means to weaken ciphers, why wouldn't you equate that to working for the NSA (or something equally bad)?

Re: NSA and IETF, part 3: Dodging the issues at hand

#76

Post by crote »

zahllos wrote: post #24

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal…

> In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange.

No, that's background dressing by now. The bigger issue is how IETF is trying to railroad a standard by violating its own procedures, ignoring all objections, and banning people who oppose it.

They are literally doing the kind of thing we always accuse China of doing. ML-KEM-only is obviously being pushed for political reasons. If you're not willing to let a standard be discussed on its technical merits, why even pretend to have a technology-first industry working group?

Seeing standards being corrupted like this is sickening. At least have the gall openly claim it should be standardized because it makes things easier for the NSA - and by extension (arguably) increasing national security!

Re: NSA and IETF, part 3: Dodging the issues at hand

#77

Post by philodeon »

jonstewart wrote: post #22
johnisgood wrote: post #8

Earlier quoted context omitted.

Why, if I might respectfully ask?

Sure! First, while I’m in no position to judge cryptographic algorithms, the success of cha-cha and 25519 speak for themselves. More prosaically, patriecia/critbit trees and his other tools are the right thing, and foresighted. He’s not just smart, but also prolific. However, he’s left a wake of combative controversy his entire career, of the “crackpot” type the parent comment notes, and at some point it’d be worth h…

[flagged]

Re: NSA and IETF, part 3: Dodging the issues at hand

#78

Post by ekr____ »

adgjlsfhk1 wrote: post #65
zahllos wrote: post #24

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal…

The problem with standardizing bad crypto options is that you are then exposed to all sorts of downgrade attack possibilities. There's a reason TLS1.3 removed all of the bad crypto algorithms that it had supported.

There were a number of things going on with TLS 1.3 and paring down the algorithm list.

First, we both wanted to get rid of static RSA and standardize on a DH-style exchange. This also allowed us to move the first encrypted message in 1-RTT mode to the first flight from the server. You'll note that while TLS 1.3 supports KEMs for PQ, they are run in the opposite direction from TLS 1.2, with the client supplying the public key and the server signing the transcript, just as with DH.

Second, TLS 1.3 made a number of changes to the negotiation which necessitated defining new code points, such as separating symmetric algorithm negotiation from asymmetric algorithm negotiation. When those new code points were defined, we just didn't register a lot of the older algorithms. In the specific case of symmetric algorithms, we also only. use AEAD-compatible encryption, which restricted the space further. Much of the motivation here was security, but it was also about implementation convenience because implementers didn't want to support a lot of algorithms for TLS 1.3.

It's worth noting that at roughly the same time, TLS relaxed the rules for registering new code points, so that you can register them without an RFC. This allows people to reserve code points for their own usage, but doesn't require the IETF to get involved and (hopefully) reduces pressure on other implementers to actually support those code points.

Re: NSA and IETF, part 3: Dodging the issues at hand

#79

Post by dataflow »

jcranmer wrote: post #40
amiga386 wrote: post #11

Earlier quoted context omitted.

It's very simple. ECC is well understood and has not been broken over many years. ML-KEM is new, and hasn't had the same scrutiny as ECC. It's possible that the NSA already knows how to break this, and has chosen not to tell us, and NIST plays the useful idiot. NIST has played the useful idiot before, when it promoted Dual_EC_DRBG, and the US government paid RSA to make it the default CSPRNG in their crypto libraries…

> Standards organisations are very easily corruptable when its members are allowed to have conflicts of interest and politick and rules-lawyer the organisation into adopting their pet standards. FWIW, in my experience on standardization committees, the worst example I've seen of rules-lawyering to drive standards changes is... what DJB's doing right now. There's a couple of other egregious examples I can think of, wh…

What exactly are you calling "rules-lawyering"? Is citing rules and pointing out their blatant violation "rules-lawyering"? If so, can you explain why it is better to avoid this, and what should be done instead?

As an outsider I'd understand it differently: reading rules and pointing out their lack of violation (perhaps in letter), when people feel like you violated it (perhaps in spirit), is what would be rules-lawyering. You're agreeing on what the written rules are, but interpreting actions as following vs. violating them.

That's quite different from an accusation of rules violation followed by silence or distortions or outright lies.

If someone is pointing out that you're violating the rules and you're lying or staying silent or distorting the facts, you simply don't get to dismiss or smear them with a label like "rules-lawyer". For rules to be followed, people have to be able to enforce them. Otherwise it's just theater.

Re: NSA and IETF, part 3: Dodging the issues at hand

#80

Post by HelloNurse »

blintz wrote: post #70
HelloNurse wrote: post #36

Earlier quoted context omitted.

The metaphor near the beginning of the article is a good summary: standardizing cars with seatbelts, but also cars without seatbelts. Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible: IETF standardization is a great opportunity for a long term social engineering operation, much like DES, Clipper, the more recent funny elliptic curve,…

> Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.

AES and RSA had enough public scrutiny to make backdooring backdoors imprudent.

The standardization of an obviously weaker option than more established ones is difficult to explain with security reasons, so the default assumption should be that there are insecurity reasons.

Post reply on HN