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

11–20 of 198 posts

Re: NSA and IETF: Fairness

#11

Post by ekr____ »

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…

Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft.

The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/), it will replace the reference in the registry. However, it will have the same code point and the same semantics. If, for some reason, the IETF were to change the semantics, a new code point would have to be assigned for interop reasons.

Re: NSA and IETF: Fairness

#12

Post by wbl »

ekr____ wrote: post #10
tptacek wrote: post #8

The two most important things to understand about this kerfuffle: (1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to cla…

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

The ISE has said they aren't progressing crypto drafts anymore.

Re: NSA and IETF: Fairness

#13

Post by eqvinox »

ekr____ wrote: post #10
tptacek wrote: post #8

The two most important things to understand about this kerfuffle: (1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to cla…

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

> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.

The IETF document only documents how and where to put the MLKEM values into TLS. MLKEM itself is specified in FIPS203 and it just references that for the actual cryptographic details. The IETF document is in fact quite short:

https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html

(This doesn't mean the document is a stub or pointless or something like that, you do need a "what goes where".)

Re: NSA and IETF: Fairness

#14

Post by eqvinox »

ekr____ wrote: post #11
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…

Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft. The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ ), it will replace the reference in the registry. However, it will have the same code point and t…

> […] "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published […]

Yes, sorry, I was just covering against people nitpicking on the document status :)

Re: NSA and IETF: Fairness

#15

Post by throw0101d »

ekr____ wrote: post #10
tptacek wrote: post #8

The two most important things to understand about this kerfuffle: (1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to cla…

> (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 standard document. No one is forcing anyone to use this algorithm, and it's not even 'officially' recommended (per above).

[1] https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

Re: NSA and IETF: Fairness

#16

Post by ekr____ »

eqvinox wrote: post #13
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…

> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM. The IETF document only documents how and where to put the MLKEM values into TLS. MLKEM itself is specified in FIPS203 and it just references that for the actual cryptographic details. The IETF document is in fact quite short: https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html (This doesn't mean the document is a stub or p…

You're right. Bad writing on my part. Edited to make it clear.

Re: NSA and IETF: Fairness

#17

Post by ButlerianJihad »

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…

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 positions such as Administrator, and the ArbCom seats, but that’s for people, not article content.)

Re: NSA and IETF: Fairness

#18

Post by eqvinox »

ekr____ wrote: post #11
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…

Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft. The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ ), it will replace the reference in the registry. However, it will have the same code point and t…

Actually… what would even be the result of the pure MLKEM document getting dropped by the IETF? I guess the entries would temporarily be marked deprecated or something, until another reference is made available somewhere, describing the same behavior? I'm not sure what procedural blockers this might run into but my general sense is that the IETF & IANA wouldn't "block off" the already allocated codepoints from being specified elsewhere (or allocate new duplicate codepoints) so long as the behavior is identical.

Re: NSA and IETF: Fairness

#20

Post by iririririr »

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.
Post reply on HN