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

181–190 of 198 posts

Re: NSA and IETF: Fairness

#181

Post by eqvinox »

phasmantistes wrote: post #170
eqvinox wrote: post #4

DJB keeps calling the IETF consensus process "voting". That's detrimental to his own case; when there is a vote, the vote can be manipulated. It makes much more sense to argue there is no consensus, which should be quite obvious at this point, and which can be argued even in a "60:40" situation regardless of direction. It also avoids alienating "true IETF believers" (ed.: I am one). Apart from that, the crux of this…

The issue with saying that "there's a 60/40 split, therefore there's no consensus" is that the IETF explicitly documents that that isn't the case: RFC 7282, Section 7, "Five people for and one hundred people against might still be rough consensus" ( https://datatracker.ietf.org/doc/html/rfc7282#section-7 ). The working group chairs have to decide if all of the objections have been "addressed". However, "addressed" do…

What I said was "It makes much more sense to argue there is no consensus […] can be argued even in a "60:40" situation regardless of direction".

Not "there's a 60/40 split, therefore there's no consensus".

Can be argued even in. That's a statement of allowance, not sufficiency. And I was speaking in the context of contrasting against a vote. You can't argue with a vote's tally.

Re: NSA and IETF: Fairness

#182

Post by grayhatter »

philodeon wrote: post #165
some_furry wrote: post #162

Earlier quoted context omitted.

You're all over the place except where the discussion was actually taking place.

Ok, let me be clear: the NIST is a proxy organization for the NSA. The declassified internal history of the NSA makes it clear that they were subverting the NIST back when they were still called the National Bureau of Standards. Just because NIST engages in some wholesome activities doesn’t mean that their core purpose isn’t to do the bidding of the NSA.

> Just because NIST engages in some wholesome activities doesn’t mean that their core purpose isn’t to do the bidding of the NSA.

Their core purpose is to recommend standards that everyone can use, and anyone who wants to work with the US government is expected to follow. They have to pick standards for everything, but can't have experts in everything on staff, so are required to defer to other experts willing to help. The NSA took advantage of them. I find the idea that NIST wants to be a lackey to the NSA, stupid. It's ignorance and incompetence that lead NIST to getting duped by the NSA. The problem is, not getting dupe is literally, their *only* job.

It's like hiring a firefighter to protect you and then they set your house on fire; it doesn't matter so much why you don't have a house anymore... you just sure a hell are never letting him near anything important every again.

You're allowed to treat gross incompetence as equivalent to intentional malice, without needing to make something up about how it was intentional.

Re: NSA and IETF: Fairness

#183

Post by tptacek »

grayhatter wrote: post #180
tptacek wrote: post #178

Earlier quoted context omitted.

You're making my point for me. Nobody in the whole world is asking for you to take NIST's word for anything. The problem here is that literally the only information you have to work with is Daniel Bernstein, a notorious standards crank. The names of the cryptographers vouching for Kyber don't mean anything to you. Peter Schwabe? Leo Ducas? Chris Peikert? You're not a cryptographer, who could reasonably expect you to…

My problem is with NIST, your problem is with DJB. Neither of us really want to defend either, (I assume, maybe you do want to defend one of them?) We just disagree which one is more likely to make the world worse. I'm not taken in by the crazyness on either side, and while if pressed, it's obvious which side I would pick. I'm not so much picking a side, so much as complaining again, how we're letting a group with an…

No, nobody is asking you to trust NIST.

Re: NSA and IETF: Fairness

#184

Post by dhx »

tptacek wrote: post #179
dhx wrote: post #176

Earlier quoted context omitted.

From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1] But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resi…

Sir, this is a Wendy's. You're giving me a phone book's worth of RFC cites here but not a lot of indication that you spend a lot of time reading RFCs generally. The RFC we're discussing on this thread is an ancillary publication documenting code points for a specific configuration of MLKEM, which is already extensively documented in other RFCs. Ancillary RFCs like these are for obvious reasons brief.

My key point you are avoiding with personal attacks is:

If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)?

--

The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort to be side channel resistant. The end state for MLKEM-only will be the IANA registry stating TLS named group 0x200 (MLKEM512) is specified in RFCxxxx (draft-ietf-tls-mlkem), and this RFC will refer to FIPS 203 for cryptographic primitives. At no time is side channel resistance in any way guaranteed by either draft-ietf-tls-mlkem or FIPS 203.

The situation for TLS named group 0x0029 (x25519) is different. The IANA registry nominates RFC 8446 as the relevant specification.[1] And RFC 8446 nominates a specification (RFC 7748) which does require implementation of cswap as a measure of side channel resistance.[2][3] So when you trace through the specifications starting from the IANA registry, it is unambiguous that TLS named group 0x0029 should provide at least some degree of side channel resistance. Even for this case, I'd argue the SHOULD would be better as a MUST (with possibility to add another TLS named group specifically for x25519-unsafe without constant-time cswap if anyone cares for it). And I'd also argue that RFC 8446/TLSv1.3 should require (not just suggest or hope) that implementations MUST only use constant time functions when processing ECDHE parameters per s4.2.8.2.[2] TSLv1.3 already requires AEAD use elsewhere to force constant-time processing. It's worth noting TLSv1.3 currently doesn't provide any guarantee about side channel resistance of secp256r1, secp384r1, and secp521r1. TLSv1.3 currently just provides this guarantee for X25519 and X448.

[1] https://www.iana.org/assignments/tls-parameters/tls-paramete...

[2] https://www.rfc-editor.org/info/rfc8446/#section-4.2.8.2

[3] https://www.rfc-editor.org/info/rfc7748/#section-5

Re: NSA and IETF: Fairness

#185

Post by chr15m »

acdha wrote: post #169
chr15m wrote: post #99

Earlier quoted context omitted.

I have edited my post to remove the rude acronym. Thank you for your feedback. I do not think the response addresses the claims made, and uses logical fallacies in place of a well reasoned response. > a team of highly-regarded European academic cryptographers This is absolutely an appeal to authority.

They didn’t get MLKEM deployed by saying “I’m a professor of computer science at $UNI, do it!” but by working within the community for many years and going through an elaborate review and standardization process with extensive peer review and public comment. That’s not infallible but it’s misleading to talk about it as if it’s the same as the U.S. federal government (a real capital-A authority) mandating it. This mat…

Correct. The argument is not about the deployment or the technical quality of MLKEM. Pretending it is, is an appeal to authority, and is moving the goal posts from the actual argument.

Re: NSA and IETF: Fairness

#186

Post by grayhatter »

tptacek wrote: post #183
grayhatter wrote: post #180

Earlier quoted context omitted.

My problem is with NIST, your problem is with DJB. Neither of us really want to defend either, (I assume, maybe you do want to defend one of them?) We just disagree which one is more likely to make the world worse. I'm not taken in by the crazyness on either side, and while if pressed, it's obvious which side I would pick. I'm not so much picking a side, so much as complaining again, how we're letting a group with an…

No, nobody is asking you to trust NIST.

Did you really need me to specify rhetorically speaking? You weren't able to work out that on your own?

Re: NSA and IETF: Fairness

#188

Post by tptacek »

dhx wrote: post #184
tptacek wrote: post #179

Earlier quoted context omitted.

Sir, this is a Wendy's. You're giving me a phone book's worth of RFC cites here but not a lot of indication that you spend a lot of time reading RFCs generally. The RFC we're discussing on this thread is an ancillary publication documenting code points for a specific configuration of MLKEM, which is already extensively documented in other RFCs. Ancillary RFCs like these are for obvious reasons brief.

My key point you are avoiding with personal attacks is: If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)? -- The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort…

This isn't responsive to anything I just wrote. Are you generating these comments?

Re: NSA and IETF: Fairness

#189

Post by ekr____ »

throw0101d wrote: post #175
ekr____ wrote: post #156

Earlier quoted context omitted.

I have no opinion on ULA+NPTv6, other than Experimental doesn't mean you shouldn't use it. How else would people experiment. It does mean that the level of vetting by the IETF is potentially lower. WRT IPv4 NAT, I'm not sure how much we can infer from the status. Many people at IETF were (and some still are) very anti-NAT, in part because they felt that IPv6 was the right solution. As a result, the IETF really avoide…

My general point is that the category or track of an RFC may mean different things to different people (assuming they're even aware of them at all).

No disagreement there.

Re: NSA and IETF: Fairness

#190

Post by wglb »

xnorswap wrote: post #83
tptacek wrote: post #66

Earlier quoted context omitted.

It's "cipher". But we're not talking about ciphers; we're talking about key establishment algorithms.

It's cypher in British English.

Isn't it true that OED say that "cipher" is the primary, preferred spelling in modern British English?
Post reply on HN