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

[Soatok Dreamseeker <[e-mail]>]

I was referring to your SafeCurves website.
https://safecurves.cr.yp.to/complete.html still says P-256 doesn't satisfy
completeness, and https://safecurves.cr.yp.to/ind.html claims it doesn't
satisfy indistinguishability.

Maybe consider updating these pages to incorporate research that's as fresh
as 11-12 years old.

On Fri, Jul 10, 2026 at 10:18 PM D. J. Bernstein <[e-mail]> wrote:

> The specific context here is that I cited a 2024 paper as follows: "For
> the concrete KEMs, https://cr.yp.to/papers.html#safecurves reviews how
> X25519 avoids various security dangers of NIST P-256."
>
> Soatok Dreamseeker writes:
> > I would like to add that SafeCurves is woefully outdated.
> > https://eprint.iacr.org/2015/1060
> > https://eprint.iacr.org/2014/043
>
> I see no justification for this claim. Can you please quote a statement
> that you claim is rendered obsolete by https://eprint.iacr.org/2015/1060
> and/or <https://eprint.iacr.org/2015/1060and/or>
> https://eprint.iacr.org/2014/043?
>
> ---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.
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>