Complaint regarding BCP 79 violations in the LAMPS WG (D. J. Bernstein) - 2025-05-01
Appeal correspondence and text contents - 2025-05-01

Date: Wed, 30 Apr 2025 20:22:28 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Complaint regarding BCP 79 violations
To: iesg@ietf.org
CC: spasm@ietf.org

Dear IESG, cc'ing spasm@ietf.org:

I am writing to file https://cr.yp.to/2025/20250430-bcp-79.pdf with you.
For transparency, please carry out all discussion of this matter on the
public mailing list spasm@ietf.org, including, but not limited to, any
discussions of this matter among IESG members, agents of IETF
Administration LLC, etc. Thanks in advance.

Date: Thu, 01 May 2025 10:38:54 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: [lamps] Complaint regarding BCP 79 violations
To: iesg@ietf.org
CC: spasm@ietf.org

Dear IESG, cc'ing spasm@ietf.org:

https://cr.yp.to/2025/20250501-bcp-79.pdf corrects a typo from the
previous filing; please use this instead of the previous filing. My
apologies for the extra paperwork.

---D. J. Bernstein

Text contents of https://cr.yp.to/2025/20250501-bcp-79.pdf downloaded at 0845 EST 01-May-2025

Complaint regarding BCP 79 violations

Daniel J. Bernstein, 2025-05-01

This is a complaint to the Internet Engineering Steering Group (IESG) regarding recent violations of two provisions of BCP 79 (RFC 8179). Despite the gentle names of IETF’s “Best Current Practice” and “Request For Comments” document series, my understanding is that BCP 79 is IETF policy and must be followed unless and until it is changed.

Procedurally, I have three independent grounds for requesting IESG attention to this matter:

  • BCP 9 (RFC 2026), Section 6.5.1, says that “If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole”. The prerequisite appears to be satisfied; see below.

  • BCP 9, Section 6.5.2, says that the IESG “is charged with ensuring that the required procedures have been followed, and that any necessary prerequisites to a standards action have been met”.

  • Standardization organizations are obliged by law to provide an appeals process and due process for all interested parties, among other obligations; see below. IETF’s handling of this matter so far is not meeting these obligations. An appeals process by itself is practically meaningless without due process.

The two BCP 79 provisions at issue are identified below. The documents at issue are https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/ and https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber/. My understanding is that the documents are under current IESG consideration (first by an IESG member designated as the relevant “area director” and then by the full IESG), making it important for IESG to handle this complaint in a timely fashion.

IETF Administration LLC claims (https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/) that “IETF activities are conducted with extreme transparency, in public forums”. The relevant public mailing list for the documents at issue is spasm@ietf.org. For transparency, please carry out all discussion of this matter on that list, including, but not limited to, any discussions of this matter among IESG members, agents of IETF Administration LLC, etc.

1. Criminal antitrust law

I’ll begin by explaining what I said above about legal obligations. I’ll focus on United States antitrust law here.

First point: an agreement in restraint of interstate commerce is a felony. Here’s what the law says (source: https://uscode.house.gov/view.xhtml?req=(title:15%20section:1%20edition:prelim):

Every contract, combination in the form of trust or otherwise, or conspiracy, in restraint of trade or commerce among the several States, or with foreign nations, is declared to be illegal. Every person who shall make any contract or engage in any combination or conspiracy hereby declared to be illegal shall be deemed guilty of a felony, and, on conviction thereof, shall be punished by fine not exceeding $100,000,000 if a corporation, or, if any other person, $1,000,000, or by imprisonment not exceeding 10 years, or by both said punishments, in the discretion of the court.

Antitrust law is in the news mainly in the context of big corporations being forcibly restructured, but https://web.archive.org/web/20250424170656/https://www.ussc.gov/sites/default/files/pdf/about/commissioners/selected-articles/Howell_Review_of_Antitrust_Sentencing_Data.pdf shows that quite a few people have been sent to jail.

Second point: the law makes an exception for standardization, but invoking the exception requires conduct to meet the law’s definition of “standards development activity”, and to by carried out by an organization meeting the law’s definition of a “standards development organization”. Here’s the exception in the law (source: https://uscode.house.gov/view.xhtml?req=(title:15%20section:4302%20edition:prelim):

In any action under the antitrust laws, or under any State law similar to the antitrust laws, the conduct of-

1) any person in making or performing a contract to carry out a joint venture, or

2) a standards development organization while engaged in a standards development activity,

shall not be deemed illegal per se; such conduct shall be judged on the basis of its reasonableness, taking into account all relevant factors affecting competition, including, but not limited to, effects on competition in properly defined, relevant research, development, product, process, and service markets.

Third point: an organization is not a “standards development organization” under this law unless it meets the OMB A-119 criteria. Here’s the definition of “standards development organization” in the law (source: https://uscode.house.gov/view.xhtml?req=(title:15%20section:4301%20edition:prelim):

The term “standards development organization” means a domestic or international organization that plans, develops, establishes, or coordinates voluntary consensus standards using procedures that incorporate the attributes of openness, balance of interests, due process, an appeals process, and consensus in a manner consistent with the Office of Management and Budget Circular Num- ber A–119, as revised February 10, 1998. The term “standards development organization” shall not, for purposes of this chapter, include the parties participating in the standards development organization.

Fourth point: the OMB A-119 criteria place specific requirements upon consensus, along with requiring openness, due process, and more. Here’s the OMB A-119 definition of a voluntary consensus standards body (source: https://www.govinfo.gov/content/pkg/FR-1998-02-19/html/98-4177.htm):

A voluntary consensus standards body is defined by the following attributes: (i) Openness. (ii) Balance of interest. (iii) Due process. (vi) An appeals process. (v) Consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.

Fifth point: activity by a standards development organization is still not “standards development activity” under the law unless it has one of the standardization/conformity-assessment purposes specifically listed in the law and avoids the activities specfically excluded in the law. Here’s the definition of “standards development activity” in the law (source: https://uscode.house.gov/view.xhtml?req=(title:15%20section:4301%20edition:prelim):

The term “standards development activity” means any action taken by a standards development organization for the purpose of developing, promulgating, revising, amending, reissuing, interpreting, or otherwise maintaining a voluntary consensus standard, or using such standard in conformity assessment activities, including actions relating to the intellectual property policies of the standards development organization. The term “standards development activity” excludes the following activities:

1) Exchanging information among competitors relating to cost, sales, profitability, prices, mar- keting, or distribution of any product, process, or service that is not reasonably required for the purpose of developing or promulgating a voluntary consensus standard, or using such standard in conformity assessment activities.

2) Entering into any agreement or engaging in any other conduct that would allocate a market with a competitor.

3) Entering into any agreement or conspiracy that would set or restrain prices of any good or service.

To summarize: Relabeling an agreement to restrain commerce as “standardization” is not a get-out-of-jail-free card. The exception in antitrust law for standardization applies only under a series of restrictions, including the following. All actions must be for the purpose of standardization or conformity assessment, and must be taken only with consensus. A consensus declaration does not require unanimity, but it must be preceded by

  • general agreement;
  • fair consideration of each comment;
  • a process of attempting to resolve each objection; and
  • documentation—for any objection that was not resolved but that was instead overridden by general agreement—of why that objection was overridden.

As further protections, there must be openness, a balance of interest, an appeals process, and due process. When all of these requirements are met, the standardization activity is not “deemed illegal per se”, and a court will instead evaluate “reasonableness” as the dividing line between the activity and a felony.

2. The BCP 79 provisions at issue

The first BCP 79 provision at issue is the “no known IPR claims” requirement for “mandatory-to-implement security technology”:

It has become common to have a mandatory-to-implement security technology in IETF technology specifications. This is to ensure that there will be at least one common security technology present in all implementations of such a specification that can be used in all cases. This does not limit the specification from including other security technologies, the use of which could be negotiated between implementations. 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. This limitation does not extend to other security technologies in the same specification if they are not listed as mandatory to implement.

The second BCP 79 provision at issue is the “change control” requirement:

The IETF must have change control over the technology described in any Standards Track IETF Documents in order to fix problems that may be discovered or to produce other derivative works.

In some cases, the developer of patented or otherwise controlled technology may decide to hand over to the IETF the right to evolve the technology (a.k.a., “change control”). The implementation of an agreement between the IETF and the developer of the technology can be complex. (See [RFC1790] and [RFC2339] for examples.)

Note that there is no inherent prohibition against a Standards Track IETF Document making a normative reference to proprietary technology. For example, a number of IETF standards support proprietary cryptographic transforms.

3. Kyber patent timeline

The factual background for the specific BCP 79 violations at issue, in short, is as follows. GAM (Gaborit and Aguilar Melchor), Ding (Jintai Ding), and Zhao (Yunlei Zhao) own patents that they say cover NIST’s new ML-KEM standard (Kyber). NIST says it has signed patent licenses for the GAM (owned by CNRS) and Ding patents, but, in the Ding case, only for exactly the NIST-standardized version of ML-KEM, not for any modifications. There have been no comments from NIST regarding the Zhao patents.

In more detail, the timeline of events is as follows:

There are two factual questions that have been raised and that don’t seem to be answered by the available documents:

  • Did NIST evaluate the Zhao patent claim regarding Kyber?

  • Why didn’t NIST post the complete signed licenses for the GAM and Ding patents?

Regarding the second question, there is a third-party claim (https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/) that NIST has released “all of the information about the licenses that it can”, but this doesn’t seem to be substantiated.

4. How these drafts violate the provisions at issue

The notation in Figure 1 as follows: “con” means an argument that the draft is violating BCP 79; “pro” means an argument that the draft isn’t violating BCP 79; “fix” means a potential way forward.

  • con: the draft does not comply with BCP 79 saying “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”
    • con: can’t implement draft without implementing Kyber
    • con: Zhao claiming “Kyber is covered by our patents” is a known IPR claim regarding Kyber
      • pro: Zhao hasn’t filed an IPR disclosure
        • con: BCP 79 says “no known IPR claims”, not “no known IPR claims for which the disclosure procedures of the document were followed”
      • pro: Zhao wrote patents are only for “credit (not for economic reasons)”
        • con: that’s irrelevant to this BCP 79 criterion
        • con: researchers normally say this; this doesn’t trigger estoppel and doesn’t stop them from asking for money (Ding asked Google for money re New Hope)
    • pro: will be good enough if there’s a royalty-free license before RFC publication, so WG can ignore this issue
      • con: BCP 79 assigns responsibility to WGs (“In general, IETF working groups prefer tech- nologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing”), not to subsequent publication stages
    • fix: BCP 79 has an exception procedure for this requirement: “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.”
      • con: procedurally, there has been no IETF-wide notification of a proposal to violate this BCP 79 principle
      • con: content-wise, there is no good reason to violate this principle, let alone a “very good reason”; should instead apply other fix above
    • fix: BCP 79 says “The IETF, following normal processes, can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted”
      • con: this is overridden by BCP 79’s subsequent text (quoted above) imposing a more specific requirement upon mandatory-to-implement security technology and imposing a higher bar for exceptions
  • con: the draft does not comply with BCP 79 saying “The IETF must have change control over the technology described in any Standards Track IETF Documents in order to fix problems that may be discovered or to produce other derivative works”
    • con: BCP 79 continues by saying it isn’t prohibiting proprietary cryptography, but requires nego- tiations with the patent holders to ensure change control, as in RFC 1790 and RFC 2339
    • con: the available edited license excerpts for Kyber say “any modification, extension, or deriva- tion of the parameters of the PQC ALGORITHM, is not an implementation or use of the PQC algorithm”
    • fix: don’t put document on standards track
    • pro: the document specifies ML-KEM only by reference
      • con: that position amounts to eliminating this BCP 79 rule
    • pro: without change control over ML-KEM, IETF can handle problems with ML-KEM by depre- cating ML-KEM
      • con: that position amounts to eliminating this BCP 79 rule

Figure 1: Arguments and counterarguments regarding the violation of these two BCP 79 rules.

Indenting B under A in the figure indicates that B is a supporting argument for A (if same pro/con) or a counterargument to A (if opposite pro/con) or a fix for A. Links are to mailing-list messages that have raised these arguments and counterarguments. The figure applies equally to both drafts.

In general, the easy way to see that the “pro” arguments in Figure 1 are flawed is to see that they prove too much: they would allow any draft to simply ignore these BCP 79 requirements.

Exception: there are two counterarguments that really are specific to the situation at hand, namely saying that Zhao (1) says his patents are only for “credit (not for economic reasons)” and (2) hasn’t filed an IPR disclosure. These counterarguments are, however, irrelevant to the clear text of the BCP 79 requirements at issue.

As for the fixes: The first fix, regarding the first BCP 79 requirement at issue, would invoke BCP 79’s procedure to make an exception to that requirement. This procedure requires documenting a “very good reason” for the particular exception, and then having this reason “agreed to through IETF consensus”. None of this has happened: there hasn’t even been the basic admission that this procedure is required.

The second fix—which is what the chairs have invoked—simply doesn’t work. It fails to address the specific BCP 79 requirements at issue; it’s another way of ignoring these requirements.

The third fix, regarding the second BCP 79 requirement at issue, is to take the document off the standards track. This has not been invoked.

5. Procedures followed so far

One of the document authors sent email dated 15 Apr 2025 10:49:09 -0400 (https://mailarchive.ietf.org/arch/msg/spasm/0B8ADZDzKFcEnioldKb2q2OZ0OM/) saying “I believe this version addresses all of WGLC comments”.

I sent email dated 16 Apr 2025 16:29:46 -0000 (https://mailarchive.ietf.org/arch/msg/spasm/7JqwocYcfHFlHaStdc-OQawM0ok/) saying “No, the draft still doesn’t address various objections summarized here: https://cr.yp.to/2025/bcp-79-issues.html”. I also pointed to where the objections had been stated on list in response to WGLC (working-group last call):

One of the WG chairs (Russ Housley) sent email dated 16 Apr 2025 16:40:36 -0400 (https://mailarchive.ietf.org/arch/msg/spasm/SH6NmKuFcf8wytTvO60MZPqY8F8/) repeating the claim that “this document is not specifying a mandatory to implement algorithm” (while ignoring my previously stated objection to that) and saying “I have explicitly asked whether the possible IPR related to ML-KEM is a concern. You are the only one to voice a concern” (which is not true—see, e.g., https://mailarchive.ietf.org/arch/msg/spasm/_aBRUG1mq3zd1wvanJimtLjEh7A/—and in any event is not a condition in the BCP 79 provisions at issue).

The chair then sent email dated 17 Apr 2025 08:37:23 -0700 forwarding one document to an area director (AD) for publication after IESG consideration (and then email dated 22 Apr 2025 09:51:11 -0700 similarly forwarding the other document).

I sent email dated 18 Apr 2025 00:40:20 -0000 (https://mailarchive.ietf.org/arch/msg/spasm/dMsFLzKwcEwowiw5uJdphOOJR6Q/) explaining what was wrong with the WG-chair response, and concluding as follows:

“Seeing the chairs now forwarding this draft for publication tells me that we’re now at the ‘disagreement cannot be resolved in this way’ part of RFC 2026, Section 6.5.1, so I’m bringing this matter to the attention of the AD, and I’m hereby requesting that the AD invoke appropriate dispute-resolution procedures under Section 6.5.1.”

The relevant paragraphs of BCP 9 (RFC 2026) are as follows:

A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group’s chair(s), who may involve other members of the Working Group (or the Working Group as a whole) in the discussion.

If the disagreement cannot be resolved in this way, any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute.

If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole. The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing.

Note that the uncontrolled discretion here (“manner of its own choosing”) is a due-process violation, as is the lack of any procedural constraints on the AD.

I sent followup email dated 18 Apr 2025 13:15:18 -0000 (https://mailarchive.ietf.org/arch/msg/spasm/tyXrEAglcUDZfGD3rWmzP2yBRJ0/) summarizing the patent timeline and the BCP 79 provisions at issue, with essentially identical text to Sections 3 and 4 of this document.

The AD’s entire “attempt to resolve the dispute”, beyond confirming receipt, consisted of email dated 25 Apr 2025 12:21:48 -0400 (https://mailarchive.ietf.org/arch/msg/spasm/FqgsTSZa0qC0dsloGOx3ScySmKA/) concluding—on the basis of the reasons reviewed below, ignoring various arguments already presented—that “no corrective action is warranted”. The specific reasons that the AD stated for this conclusion were as follows:

  • First, the AD claimed that the “working group concluded that there is not an active IPR disclosure for formal consideration”.
    The phrases “active IPR disclosure” and “formal consideration” are ambiguous and do not appear in BCP 79. Also, attributing a position to the WG requires that position to have WG consensus established after being specifically brought to the WG for last call, but the AD provided no URL justifying this.
    As I had already pointed out (with no response), the first BCP 79 provision says “no known IPR claims”, not “no known IPR claims for which the disclosure procedures of the document were followed”. There is indisputably a known IPR claim from Zhao regarding Kyber. The fact that Zhao hasn’t followed BCP 79’s disclosure procedures is irrelevant to this BCP 79 provision. (It’s also irrelevant to the second BCP 79 provision, the change-control requirement.)

  • Second, the AD claimed that the way that these drafts mandate Kyber does not meet the “mandatory to implement” part of the first BCP 79 provision, since other specifications don’t mandate usage of these drafts.
    As I had already pointed out (with no response), the question posed by this BCP 79 text (“no mandatory-to-implement security technology can be specified in an IETF specification unless . . . ”) is whether the specification mandates the technology. Misrepresenting the question as whether something else mandates the specification would make this BCP 79 rule useless.

  • Third, regarding the second BCP 79 provision at issue, the AD claimed that the BCP 79 change-control requirement “refers to the content of this document only, not any normatively referenced algorithms”.
    This is contrary to both the text and purpose of this BCP 79 provision. Here is the provision again: “The IETF must have change control over the technology described in any Standards Track IETF Documents in order to fix problems that may be discovered or to produce other derivative works.”
    It doesn’t matter whether a technology is described by reference to another document or by repeating the contents of that document: either way, it is part of what the standard is describing, and IETF must have change control.
    As I had already pointed out (with no response), making an exception for technology described by reference amounts to eliminating this BCP 79 rule. Any standard would be able to factor out patented technology into a separate informational document cited as a normative reference.
    The AD also quotes BCP 79 saying the following: “Note that there is no inherent prohibition against a Standards Track IETF Document making a normative reference to proprietary technology. For example, a number of IETF standards support proprietary cryptographic transforms.” This is not making an exception to the change-control rule; it is observing that the change-control rule is not inherently prohibiting proprietary technology.
    Within the broad area covered by the Ding patent, NIST has a license only for exactly NIST’s standard version of ML-KEM. The license explicitly forbids changes. This lock-in is very different from the situation of a narrow patent where changing to a different technology is simply outside the patent holder’s control.

  • Finally, regarding the false (still not withdrawn) “addresses all of WGLC comments” claim, the AD said that there is no “requirement in the IETF process” to correct the statement.
    Misinformation about the status of objections is a due-process violation, and a violation of the specific “advised of the disposition” requirement.

It is not clear that the “cannot be resolved by the Area Director(s)” text in BCP 9 includes situations where the Area Director decides to take one side without engaging with what the other side said. However, using this as a reason to bar an appeal would violate the legal requirement of an appeals process.