[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

"D. J. Bernstein" <djb@cr.yp.to> Fri, 29 November 2024 01:14 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 98F0CC1519AD for <saag@ietfa.amsl.com>; Thu, 28 Nov 2024 17:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 tiYXBpsUF56E for <saag@ietfa.amsl.com>; Thu, 28 Nov 2024 17:14:10 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 97FDFC14F6BE for <saag@ietf.org>; Thu, 28 Nov 2024 17:14:10 -0800 (PST)
Received: (qmail 10162 invoked by uid 1010); 29 Nov 2024 01:14:08 -0000
Received: from unknown (unknown) by unknown with QMTP; 29 Nov 2024 01:14:08 -0000
Received: (qmail 1048703 invoked by uid 1000); 29 Nov 2024 01:13:55 -0000
Date: Fri, 29 Nov 2024 01:13:55 -0000
Message-ID: <20241129011355.1048701.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: <4855756A-0AB8-44C1-9A44-45D477E0A548@aiven.io>
Message-ID-Hash: H3F6RJB55SUYF5IEIENNR7ZETU47J3MJ
X-Message-ID-Hash: H3F6RJB55SUYF5IEIENNR7ZETU47J3MJ
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-saag.ietf.org-0; header-match-saag.ietf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt
List-Id: Security Area Advisory Group <saag.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/yzZvJ5Fm_th7Q5qAh0A41OIxW-Q>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Owner: <mailto:saag-owner@ietf.org>
List-Post: <mailto:saag@ietf.org>
List-Subscribe: <mailto:saag-join@ietf.org>
List-Unsubscribe: <mailto:saag-leave@ietf.org>

Paul Wouters writes:
> The rough consensus is that there is no appetite for NTRUprime.

Um, what? There are multiple interoperable NTRU Prime implementations
for SSH, plus NTRU Prime implementations for various other protocols.
The SSHM WG adopted draft-josefsson-ntruprime-ssh earlier this month:

    https://mailarchive.ietf.org/arch/msg/ssh/yQrbHFDt085REimIkuWrnNqGgKU/

Consensus to adopt doesn't establish consensus regarding any particular
followup action, but it does override the earlier AD efforts to block
that document. Obviously there's interest in NTRU Prime.

At first glance, having IETF work on Kyber _and_ NTRU Prime, two small
lattice-based encryption systems, might seem redundant. However, a
closer look shows reasons to not be satisfied with Kyber, the most
obvious being the patent minefield surrounding Kyber:

    https://mailarchive.ietf.org/arch/msg/saag/b2EYReik4ziPXhSC7kw-ajQzc8w/

For example, the holder of patents CN107566121 etc. has written "Kyber
is covered by our patents". Those patents were filed before Kyber was
published. The patents will expire in 2036.

BCP 79 includes the following requirement:

    An IETF consensus has developed that no mandatory-to-implement
    security technology can be specified in an IETF specification unless
    it has no known IPR claims against it or a royalty-free license is
    available to implementers of the specification. It is possible to
    specify such a technology in violation of this principle if there is
    a very good reason to do so and if that reason is documented and
    agreed to through IETF consensus.

Documents in some IETF protocol contexts are violating this rule by
proposing Kyber as their only post-quantum encryption option. These
documents don't argue that the patent issues are outweighed by
technology issues that trigger a BCP 79 exception; the documents simply
ignore the patent issues.

I'd think that the ADs are responsible for enforcing this BCP 79
requirement. Instead the ADs seem to be _encouraging_ having Kyber as
the only post-quantum encryption option. This is a big problem. We've
already seen the same patent minefield causing years of delays in
post-quantum rollout, even without any patent holders having filed
lawsuits yet.

---D. J. Bernstein