Re: [saag] SSH & Ntruprime

[Paul Wouters <[e-mail]>]

On Wed, Apr 10, 2024 at 7:29 AM D. J. Bernstein <[e-mail]> wrote:

> Paul Wouters writes:
> > On Fri, Apr 5, 2024 at 12:28 PM D. J. Bernstein <[e-mail]> wrote:
> > > The elephant in the room is the patent minefield surrounding Kyber.
> > I do not see how this relates to a request for an AD sponsored draft
> > for NTRUprime for SSH.
>
> Simplest answer: The Crypto Review Panel review in question (1) says
> that it's not clear why to consider sntrup given NIST's selection of
> Kyber


That was one of their considerations, yes. The fact that the cryptographic
research communities are focusing on NIST candidates does mean that
those proposed algorithms will see a lot more scrutiny and research. Similar
to how TWOFISH and SERPENT didn't really see much research once RIJNDAEL
became AES. Are those two algorithms safe? Probably? Likely? Maybe? But
we wouldn't recommend their use now and I would also not AD sponsor TWOFISH
or
SERPENT at this time either. Some of the NIST candidates were broken
because they
were scrutinized because they were candidates. Should the IETF really
recommend a
dropped candidate at this stage? I do not think so, and that is not a
political argument.

The Crypto Panel review also listed some technical points, which you seem to
have left out in your latest email:

My suggestions are to describe much more more explicitly the combiner
use (typically CAT then KDF), quote the relevant literature (on
combiners and previous attempts on hybrid KEM for SSH such as [PQSSH1])
and consider including ML-KEM.

The normal IETF process is that change control is with the IETF. Would the
draft
authors be willing to make the changes recommended by the Crypto Panel? If
not,
what would be the reason for IETF to continue publication and lend its
reputation
to this then uncooperative team?


> , but (2) fails to consider the IETF policy preference for choices
> with no known patent claims. See my previous message for further details
> and other connections.
>

Patent claims are not the issue, as long as the conditions for using the
patents are not encumbered.
It seems that those will not be an issue as otherwise the NIST chosen
algorithm would not be useful.
In the unlikely case that this would become a problem, the IETF would look
at the international cryptographic
community (via CFRG) on next steps. While NTRUprime might be one of the
alternatives, it is not at all clear
that would be the most favourable alternative. I understand you feel
differently.


> > Luckily, and due to the transparency of  all IETF processes, you seem
> > to have managed to find the review I was talking about.
>
> To clarify, are you sure that your summary was talking about the review
> that I quoted?


That is correct.


> If so, can you please explain how readers can match your
> summary to the review text?
>

I will let readers read for themselves. Both messages are in the public
archive.

> Note that I also heard a similar position about NTRUprime from outside
> > the IETF in the academic world of cryptography.
>
> To clarify, are you referring to _public_ claims? If so, please provide
> a URL. If not, can you please clarify how inserting rumors into IETF
> discussions and advocating decisions on that basis is compatible with
> "the transparency of all IETF processes"?
>

These were informal conversations I had. I will let those people make their
own decisions about
stating things publicly. Some people prefer to not engage with you due to
previous negative
experiences with your method of discussion.

Anyone who feels uncomfortable with the reference I made should attach a
zero weight to it.


> > >
> https://mailarchive.ietf.org/arch/msg/crypto-panel/kDiLLcVOhwoix5BUDdv4r91ZhfY/
> > > whose comments about sntrup (1) are purely political and (2) fail to
> say
> > > anything about patents.
> > This is an at hominem attack that violates the code of conduct as
> > specified in RFC 7154.
>
> Absolutely not. These are observations about the text of the review and
> have nothing whatsoever to do with the question of who wrote the review.
> I also quoted the text, so everyone can see that it isn't a review of
> the technology and isn't saying anything about patents; it's pointing to
> NIST's selection of Kyber and making claims about popularity before and
> after the selection. Here's the text again:
>

I think I addressed this above as well. Stating one group of algorithms is
seeing much more public discourse
than others because of their appearance in a NIST competition is not making
a political statement.


> Responding to such a challenge by characterizing it as an ad-hominem
> attack is factually incorrect and actively interferes with proper
> handling of the challenge.
>

I disagree. Additionally, you did not seem to respond to the technical
issues raised in that same review, such
as the issue of the combiner being underspecified and subpar. Are the draft
authors willing to remediate this
in the draft?

And to close one last point on your statement that Roman promised
publication, please see:

https://mailarchive.ietf.org/arch/msg/secdispatch/uM9_Vy97C53MWoLSFNuRKUC6iuA/

Roman said he was "going to AD sponsor", pending some items, such as the
Crypto Panel Review, to ensure
new cryptography to the IETF wouldn't be included without vetting.
Unfortunately, that review did raise some issues,
and Roman did not proceed.

To summarize again. An IETF codepoint is not necessary for deploying
NTRUprime with SSH, as the current
widely deployed OpenSSH implementation shows. The IETF has a process for
cryptographic algorithm selections,
which should not normally be bypassed by a non-consensus "AD sponsored"
route. As deployment is already
widespread according to the proponents, the IETF is not blocking the use of
NTRUprime.

I do not believe an AD sponsored RFC that rubberstamps an outside
cryptographic algorithm, which cryptographic
experts inside the IETF would want to see improved before publication, is
currently warranted.

Paul