[CFRG] Re: RG Last Call on draft-irtf-cfrg-hybrid-kems-12 and draft-irtf-cfrg-concrete-hybrid-kems-04

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

Muhammad Usama Sardar writes:
> When you say "models," can I think of it as follows: say we have a /new/
> algorithm A. You predict failures (somehow; I don't know how you will do
> that because it is /new/) and then you keep testing it over time, and
> improving those models. Is it roughly correct? If not, could you please
> clarify that in simple words without using fancy cryptographic terms?

https://arxiv.org/abs/2107.04940 studied hundreds of CVEs in crypto
libraries. There was roughly 1 new CVE per 1000 lines of new code. About
1 out of 8 "cryptographic" CVEs was severe.

So: If you see a new algorithm, estimate how many lines of code it'll
add to crypto libraries, divide by 1000 to estimate the number of CVEs,
and divide by 8 to estimate the number of severe CVEs.

Refined models look at aspects of code beyond code volume. For example,
defense-in-depth mechanisms such as ECC+PQ obviously need a different
analysis. Also, there's an extensive literature on how various test
mechanisms interact with different types of code. Furthermore, it's
often possible to redesign cryptosystems in a way that stops various
common mistakes from causing problems.

> For a cryptographic proof in CryptoVerif, probabilities are used for the
> primitives. I am trying to understand if this failure prediction has got
> anything to do with that.

Those are referring to another source of security failures, namely the
success probability of attack algorithms against specs---e.g., a key
search might luckily find the secret key.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead with
modification, such as (1) IESG's May 2025 posting of an IESG-mangled
version of an appeal that I had filed and (2) IETF management selling
IETF mailing-list text to AI companies. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.