Re: [saag] SSH & Ntruprime
"D. J. Bernstein" <djb@cr.yp.to> Mon, 15 April 2024 22:42 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1294C14CE4D for <saag@ietfa.amsl.com>; Mon, 15 Apr 2024 15:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.194
X-Spam-Level:
X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjrDd-dVx8IL for <saag@ietfa.amsl.com>; Mon, 15 Apr 2024 15:42:30 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 6E0DDC14F71C for <saag@ietf.org>; Mon, 15 Apr 2024 15:42:30 -0700 (PDT)
Received: (qmail 25792 invoked by uid 1010); 15 Apr 2024 22:42:29 -0000
Received: from unknown (unknown) by unknown with QMTP; 15 Apr 2024 22:42:29 -0000
Received: (qmail 119550 invoked by uid 1000); 15 Apr 2024 22:42:18 -0000
Date: Mon, 15 Apr 2024 22:42:18 -0000
Message-ID: <20240415224218.119548.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@ietf.org
Mail-Followup-To: saag@ietf.org
In-Reply-To: <CAGL5yWbdAD31-cA15MACTq5OF=iZPU7qAGKfKJoPy3zNio=cnA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/M9VBit3EpuuHGD-is47xlr_H9XQ>
Subject: Re: [saag] SSH & Ntruprime
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2024 22:42:34 -0000
Paul Wouters writes: > Should the IETF really recommend a dropped candidate at this stage? Yes. IETF policy prefers algorithms with no known patent claims. BCP 79 does not authorize delegating IETF's patent-related decisions to NIST. Furthermore, the notion that NIST is speaking for a unified community is easy to disprove. For example, https://web.archive.org/web/20230401090854/https://secdev.ieee.org/wp-content/uploads/2022/10/LaMacchia-Keynote-IEEESecDev2022.pdf revealed that ISO's crypto group agreed---in October 2022, months after NIST announced its selection---to initiate a preliminary work item on a very different list of algorithms. There are three algorithms on that list; one matches a NIST selection (Kyber), one is under consideration by NIST for possible future standardization (Classic McEliece), and one was dropped by NIST (FrodoKEM). > Patent claims are not the issue, as long as the conditions for using > the patents are not encumbered. As I wrote before: "there are other patents in the area, including at least one patent holder publicly claiming Kyber coverage, with no public response from NIST or from the Kyber team". I quoted and cited a message that says "Kyber is covered by our patents"; I commented that the author of that message "holds patents CN107566121 etc., filed before Kyber was published". Clearly this qualifies as a "known IPR claim" under BCP 79. I see no evidence of an "offer of royalty-free licensing" under BCP 79. > It seems that those will not be an issue as otherwise the NIST chosen > algorithm would not be useful. My message already cited examples of the patent minefield to some extent delaying and to some extent deterring Kyber deployment. If "will" is alluding to the activation of the patent licenses once NIST actually issues a standard: sure, that deals with two patents (assuming NIST has been correctly summarizing the license terms), but the minefield is bigger than that, as illustrated by the further patent claim above. > The Crypto Panel review also listed some technical points, which you > seem to have left out in your latest email No, I didn't leave them out. I explicitly focused on the Crypto Review Panel comments regarding sntrup---because I was explicitly replying to comments you made regarding sntrup. Here's your text (followed by many more recent references to NIST's actions regarding sntrup): With this NTRUprime case, we have a less clear example. Itâs not broken but the IETF Crypto Panel also said the cryptographic method used was somewhat dated and would no longer be recommended by the larger cryptographic community at this point. Your SAAG presentation at IETF 119 claimed that the review had said "we would have done it like this 15 years ago but these days we wouldn't do it like this anymore so we shouldn't really like standardize that". Looking broadly at how the review as a whole is being used, I see four basic issues: * The review and the followup action both failed to consider the patent situation. This is not in line with BCP 79. * The portion of the review regarding sntrup was completely non-technical, with no evident content beyond delegating IETF/IRTF cryptographic decisions to NIST. The review was not "critical, objective, timely and consistent review of cryptographic algorithms". * While I agree that the review did make technical comments regarding an issue beyond sntrup (the choice of combiner), those comments are not even marginally consistent with how combiners are being handled elsewhere in IETF and IRTF. (In case readers are interested in the details, see postscript below.) * The text of the review does not match what it has been portrayed in SAAG as saying. As an example of the last issue: The SAAG portrayal is that the review text expressed opposition to documentation and/or standardization of what has been deployed in real-world SSH. The actual review text https://mailarchive.ietf.org/arch/msg/crypto-panel/kDiLLcVOhwoix5BUDdv4r91ZhfY/ sounds much less extreme, with mere "suggestions" to "describe much more explicitly the combiner use", to add citations, and to "consider" including Kyber. As another example, I see nothing in the review text assigning a positive/negative rating, so it's improper to attribute such a rating to the review. This rating appears to be something that a particular AD projected onto the review. The source should be properly labeled. > The fact that the cryptographic research communities are focusing on > NIST candidates does mean that those proposed algorithms will see a > lot more scrutiny and research. The hypothesis and conclusion of this circular argument are both easily disproven by the available data. Skimming https://eprint.iacr.org/2024 from top down right now for the ten most recent post-quantum papers, I find the following: https://eprint.iacr.org/2024/564 (attacking isogenies generally) https://eprint.iacr.org/2024/561 (an isogeny proposal) https://eprint.iacr.org/2024/555 (attacking lattices generally) https://eprint.iacr.org/2024/551 (Kyber and NewHope) https://eprint.iacr.org/2024/548 (NTRU) https://eprint.iacr.org/2024/530 (an NTRU variant) https://eprint.iacr.org/2024/523 (Kyber) https://eprint.iacr.org/2024/512 (Dilithium) https://eprint.iacr.org/2024/500 (SPHINCS+) https://eprint.iacr.org/2024/490 (new MPC-based signatures) A solid half of these are on algorithms that have been either removed by NIST or that are newer than anything submitted to NIST. Another two are _overlapping_ NIST but also including other cryptosystems. Only three fit within the alleged "focus". > that is not a political argument The text I quoted from the Crypto Review Panel regarding sntrup is purely making claims about politics (again, dictionary definition: "competition between competing interest groups or individuals for power and leadership"). Making claims that _aren't_ in the text, and saying that _those_ claims aren't political, doesn't contradict this. More to the point, my description of the review had nothing whatsoever to do with the identity of the reviewer, so it wasn't an ad-hominem attack. Please withdraw your claim to the contrary. > Some people prefer to not engage with you due to previous negative > experiences with your method of discussion. Now _that's_ an ad-hominem attack. Please (1) apologize and (2) keep yourself under control in the future. Thanks in advance. Getting back to sntrup: You've referred to secret "informal conversations" as supposedly justifying opposition to sntrup. Let me point out that this provides an easy explanation for the gaps between * the Crypto Review Panel text and * your description of that text. Specifically, couldn't it be that what you're attributing to the Crypto Review Panel is actually what's coming from those secret conversations, and you simply lost track of the source? Also, have you considered the possibility that the conclusions in those conversations come from underlying errors that would be corrected if the arguments were raised in public? Look at the above "scrutiny" claim: it's the sort of error that can easily be repeated because it _sounds_ reasonable, but transparency allows the claim to be rapidly debunked. > your statement that Roman promised publication [ etc. ] I don't know what statements you're referring to here; certainly they're not from me. If you're mixing up the NTRU Prime team, the OpenSSH team, the author list for this I-D, etc., then please be more careful. ---D. J. Bernstein P.S. In case readers are interested, here's the combiner issue. One way to combine pre-quantum and post-quantum shared secrets into a key for (e.g.) AES-256 or ChaCha20 is to hash the concatenation of the secrets. This is typically just fine, the main risk being that * quantum computers break the pre-quantum system and * a bad choice of post-quantum system is also breakable (as in the CECPQ2b experiment, which used SIKE to encrypt real user data). However, there are various papers pointing out contexts where stopping attacks requires hashing more than the shared secrets. All security recommendations in these papers are handled by a combiner that hashes the shared secrets and the full transcript (pre-quantum and post-quantum public keys and ciphertexts). Someone reviewing a combiner with anything less than transcript hashing has to look at the context and ask whether skimping on the hashing is safe in that context. It's easier for the reviewer to skip this review and just say "Why aren't you hashing more?". That's what happened in the Crypto Review Panel review of the combiner in this SSH draft---it wasn't reviewing whether this is safe in SSH; it was pointing out that this is doing something that in _some_ contexts is unsafe. Transcript hashing is cheap. I like making cryptographic choices that save time for reviewers. So I'd like to see new proposals settling on _one_ combiner that includes transcript hashing. (To be clear, I don't see this as an argument against documenting something that has been widely deployed for two years now.) Meanwhile there are other people saying that transcript hashing costs millions of dollars in aggregate and that any unnecessary hash should be skipped---even if this means that reviewers have to look at different combiners for different contexts, and check that each of the faster combiners is safe in the contexts where the combiner is being used. Here are three examples of combiners not using full transcript hashing: * A proposal called "X-Wing" uses an ad-hoc "QSF" combiner. This combiner is unsafe in some contexts. * draft-ietf-tls-hybrid-design uses a simple concatenation combiner. This combiner is unsafe in some contexts. * draft-josefsson-ntruprime-ssh uses a simple concatenation combiner, This combiner is unsafe in some contexts. Now compare how this context switch is being handled: * X-Wing is currently under consideration by CFRG. * My understanding is that draft-ietf-tls-hybrid-design has reached consensus except for settling some code points. * Meanwhile an AD is opposing draft-josefsson-ntruprime-ssh, where, as far as I can tell, the only _technical_ complaint is that it's using a concatenation combiner. This is not even marginally consistent. Sure, X-Wing is in CFRG and hasn't reached consensus, but this procedural distinction doesn't work for the TLS example, and it's also missing the point about the content. The Crypto Review Panel charter asks for "consistent review"; given that new proposals are being allowed in CFRG and TLS with combiners that can be unsafe in other contexts, why is draft-josefsson-ntruprime-ssh being selectively targeted with a complaint that its combiner can be unsafe in other contexts?
- [saag] SSH & Ntruprime Loganaden Velvindron
- Re: [saag] SSH & Ntruprime D. J. Bernstein
- Re: [saag] SSH & Ntruprime Harry Halpin
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Paul Wouters
- Re: [saag] SSH & Ntruprime Simon Josefsson
- Re: [saag] SSH & Ntruprime Loganaden Velvindron
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Orie Steele
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Jan-Frederik Rieckers
- Re: [saag] SSH & Ntruprime Orie Steele
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Orie Steele
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Melinda Shore
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime Ira McDonald
- Re: [saag] SSH & Ntruprime Michael Richardson
- Re: [saag] SSH & Ntruprime Paul Wouters
- Re: [saag] SSH & Ntruprime Simon Josefsson
- Re: [saag] SSH & Ntruprime Christian Huitema
- Re: [saag] SSH & Ntruprime Russ Housley
- Re: [saag] SSH & Ntruprime Orie Steele
- Re: [saag] SSH & Ntruprime Michael Richardson
- Re: [saag] SSH & Ntruprime Loganaden Velvindron
- Re: [saag] SSH & Ntruprime Loganaden Velvindron
- Re: [saag] SSH & Ntruprime Michael Richardson
- Re: [saag] SSH & Ntruprime Paul Wouters
- Re: [saag] SSH & Ntruprime Michael Richardson
- Re: [saag] SSH & Ntruprime Michael Richardson
- Re: [saag] SSH & Ntruprime Paul Wouters
- Re: [saag] SSH & Ntruprime Stephen Farrell
- Re: [saag] SSH & Ntruprime Simon Josefsson
- Re: [saag] SSH & Ntruprime Mark Baushke (ietf)
- Re: [saag] SSH & Ntruprime Stephen Farrell
- Re: [saag] SSH & Ntruprime D. J. Bernstein
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Stephen Farrell
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Paul Wouters
- Re: [saag] SSH & Ntruprime Watson Ladd
- Re: [saag] SSH & Ntruprime Stephen Farrell
- Re: [saag] SSH & Ntruprime Simon Josefsson
- Re: [saag] SSH & Ntruprime StJohns, Michael
- Re: [saag] SSH & Ntruprime Watson Ladd
- Re: [saag] SSH & Ntruprime Stephen Farrell
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime Watson Ladd
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Eric Rescorla
- Re: [saag] SSH & Ntruprime D. J. Bernstein
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Paul Wouters
- Re: [saag] SSH & Ntruprime D. J. Bernstein
- Re: [saag] SSH & Ntruprime Deb Cooley
- Re: [saag] SSH & Ntruprime Christian Huitema
- Re: [saag] SSH & Ntruprime Simon Josefsson