[lamps] Re: WG Last Call for draft-ietf-lamps-kyber-certificates-07

["D. J. Bernstein" <[e-mail]>]

Russ Housley writes:
> there are no IPR disclosures, including third-party IPR disclosures,
> against this document

Here's the BCP 79 rule I quoted: "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."

This says "no known IPR claims". It isn't limited to claims for which
the disclosure procedures of the document were followed.

> This is not a mandator-to-implement algorithm.  If one chooses to
> implement this specification, then that implementer will obviously
> need to implement ML-KEM.

That makes the algorithm mandatory to implement.

> Implementation of this specification is
> completely voluntary, even if it is published as a standards-track RFC.

The rule is for "mandatory-to-implement security technology ... in an
IETF specification".

Replacing this with "security technology ... in an IETF specification
that something else mandates implementing" would make the rule useless:
a new spec isn't required by anything yet.

More to the point, that isn't what the rule says. The question isn't
whether something external is mandating the spec; the question is
whether the patented technology is mandated by the spec.

> The IETF does have change control over this specification, but it does
> not have change control over ML-KEM.

So anyone who wants to violate the BCP 79 requirement of change control
can simply factor the part that IETF can't change into an external spec,
and still have IETF mandate usage of that spec? No need for agreements
such as RFC 1790 and RFC 2339! This evasion is completely undermining
the purpose and effect of IETF having change control.

> If a problem is ever discovered with ML-KEM, then the IETF will have
> two choices.  The IETF can work with NIST to resolve the problem, or
> the IETF can deprecate the use of ML-KEM.

One could equally well argue, for any X where IETF doesn't have change
control, that IETF can handle a problem with X by trying to resolve the
problem or by deprecating the use of X.

The users who trusted IETF and deployed X have an easier time deploying
a tweak to X than deploying something completely different. This puts
the patent holder in a perfect position to make money, charging everyone
for the privilege of using a tweak for X.

This is contrary to the whole idea of avoiding patented technology.
Sure, the money-making happens only when X turns out to be flawed, but
flaws are found in IETF specs all the time. This is incentivizing patent
holders to allow IETF free usage of specific options, betting (or maybe
even knowing) that users will want tweaks later. IETF should be avoiding
this trap and instead putting effort into patent-free alternatives.

Anyway, these discussions of the merits of IETF change control are not
what matters for this WGLC. What matters is that BCP 79 is IETF policy
and requires change control for anything on the standards track.

---D. J. Bernstein