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

121–130 of 249 posts

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

#121

Post by dataflow »

jcranmer wrote: post #92
crote wrote: post #73

Earlier quoted context omitted.

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…

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…

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

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

#122

Post by ekr____ »

jcranmer wrote: post #99
adgjlsfhk1 wrote: post #96

Earlier quoted context omitted.

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.

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

#123

Post by tptacek »

johncolanduoni wrote: post #111
glitchc wrote: post #107

Earlier quoted context omitted.

> No, the argument is that the algorithm (as specified in the standard) is difficult to implement correctly, so we should tweak it/find another one. This argument is without merit. ML-KEM/Kyber has already been ratified as the PQC KEM standard by NIST. What you are proposing is that the NIST process was fundamentally flawed. This is a claim that requires serious evidence as backup.

DJB has specific (technical and non-conspiratorial) bones to pick with the algorithm. He’s as much an expert in cryptographic implementation flaws and misuse resistance as anybody at NIST. Doesn’t mean he’s right all the time, but blowing him off as if he’s just some crackpot isn’t even correctly appealing to authority. I hate that his more tinfoil hat stuff (which is not totally unjustified, mind you) overshadows hi…

There are like 3 cryptographers in all of NIST. NIST was a referee in the process. The bones he's picking are with the entire field of cryptography, not just NIST people.

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

#124

Post by themafia »

UltraSane wrote: post #56
supernetworks_ wrote: post #39

Earlier quoted context omitted.

It would be wise for people to remember that it’s worth doing basic sanity checks before making claims like no backdoors from the NSA. strong encryption has been restricted historically so we had things like DES and 3DES and Crypto AG. In the modern internet age juniper has a bad time with this one https://www.wired.com/2013/09/nsa-backdoor/ . Usually it’s really hard to distinguish intent, and so it’s possible to de…

The NSA changed the S-boxes in DES and this made people suspicious they had planted a back door but then when differential cryptanalysis was discovered people realized that the NSA changes to S-boxes made them more secure against it.

The NSA also wanted a 48 bit implementation which was sufficiently weak to brute force with their power. The industry and IBM initially wanted 64 bit. IBM compromised and gave us 56 bit.

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

#125

Post by tptacek »

supernetworks_ wrote: post #39
Foxboron wrote: post #32

Earlier quoted context omitted.

> See for example the many problems of NIST P-224/P-256/P-384 ECC curves What are those problems exactly? The whitepaper from djb only makes vague claims about NSA being a malicious actor, but after ~20 years no known backdoors nor intentional weaknesses has been reliably proven?

It would be wise for people to remember that it’s worth doing basic sanity checks before making claims like no backdoors from the NSA. strong encryption has been restricted historically so we had things like DES and 3DES and Crypto AG. In the modern internet age juniper has a bad time with this one https://www.wired.com/2013/09/nsa-backdoor/ . Usually it’s really hard to distinguish intent, and so it’s possible to de…

It's "Dragonblood", not "Dragonbleed". I don't like Harkin's PAKE either, but I'm not sure what fundamental attribute of it enables the downgrade attack you're talking about.

When you're talking about the P-curves, I'm curious how you get your "sanity check" argument past things like the Koblitz/Menezes "Riddle Wrapped In An Enigma" paper. What part of their arguments did you not find persuasive?

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

#127

Post by blintz »

dataflow wrote: post #75
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 sha…

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

If an organization wants to force its clients or servers to use pure ML-KEM, they can already do this using any means they like. The standardization of a TLS ciphersuite is besides the point.

> He comes with historical and procedural evidence of bad faith. Why is this ridiculous?

Yes, the NSA has nefariously influenced standards processes. That does not mean that in each and every standards process (especially the ones that don't go your way) you can accuse everyone who disagrees with you, on the merits, of having some ulterior motive or secret relationship with the NSA. That is exactly what he has done repeatedly, both on his blog and on the list.

> why wouldn't you equate that to working for the NSA (or something equally bad)?

For the simple reason that you should not accuse another person of working for the NSA without real proof of that! The standard of proof for an accusation like that cannot be "you disagree with me".

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

#128

Post by dwaite »

ImPostingOnHN wrote: post #85
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…

> Accusing the chairs of corruption may have influenced how seriously his complaint was taken. If you alter your official treatment of somebody because they suggested you might be corrupt (in other words, because of personal animus), then you have just confirmed their suggestion.

So all someone who is being abusive has to do to force me to be stand there and be abused by them is to call me corrupt?

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

#129

Post by yardstick »

f33d5173 wrote: post #50
abhv wrote: post #14

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

A consensus is 100%. A rough consensus should be near 100%. 2/3 is a super majority. That's a very different standard.

See https://news.ycombinator.com/item?id=46035639

A consensus isn’t always 100%

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

#130

Post by ImPostingOnHN »

dwaite wrote: post #128
ImPostingOnHN wrote: post #85

Earlier quoted context omitted.

> Accusing the chairs of corruption may have influenced how seriously his complaint was taken. If you alter your official treatment of somebody because they suggested you might be corrupt (in other words, because of personal animus), then you have just confirmed their suggestion.

So all someone who is being abusive has to do to force me to be stand there and be abused by them is to call me corrupt?

> So all someone who is being abusive has to do to force me to be stand there and be abused by them is to call me corrupt?

In this example, rectifying concerns is your job, so yes, you have to do it, even if 1 of the 7 parties who hold the concern is a jerk*. Officials can't dispense with rules and procedure just because their feelings are hurt.

If you are actually corrupt**, it isn't abuse. If you aren't, it still isn't abuse. Even if it is abuse, and you deal with it sanctions, you must still rectify the substance of the concerns upheld by 6 other parties.

* 1/7 would be a pretty desirable jerk/total ratio, in my experience

** (and officially behaving differently based on personal animus makes one so)

Post reply on HN