Background: see separate page

Notation: con = argument against the draft; pro = argument for the draft; fix = potential way forward; indenting B under A indicates that B is a supporting argument for A (if same pro/con) or counterargument to A (if opposite pro/con) or fix for A

BCP 79 issues:

• 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

    • fix: modify draft to allow alternatives to Kyber

    • pro: implementation of this spec is completely voluntary, ergo nothing in the spec is mandatory to implement (comment) (comment)

      • con: that position would make this BCP 79 rule useless (comment) (comment)

  • 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 technologies 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 negotiations 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 derivation 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 deprecating ML-KEM

    • con: that position amounts to eliminating this BCP 79 rule