Re: [saag] SSH & Ntruprime

[Paul Wouters <[e-mail]>]

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.

[cut text on patents and IPR policies that does not relate to this thread
for a code point for NTRUprime for SSH ]

Paul Wouters writes, regarding sntrup:
> > It's not broken but the IETF Crypto Panel also said the cryptographic
> > method used was somewhat dated and would no longer be recommended by
> > the larger cryptographic community at this point.
>
> Hmmm. No citation is provided here, and readers are forced to wonder
> whether this could possibly be an accurate summary of a review from the
> Crypto Review Panel
>

Luckily, and due to the transparency of  all IETF processes, you seem to
have managed to find the review I was talking
about. It seems you just forgot to remove this section from your draft
email.

[cut hypothesis about the content of crypto panel review]

Content-wise, these "dated" and "community" claims appear to be
> insinuating that sntrup has held up worse from a security perspective
> than other lattice KEMs. That's simply not true.


Feel free to have a discussion on this with the relevant people. Probably
the appropriate list would be CFRG. Note that I
also heard a similar position about NTRUprime from outside the IETF in the
academic world of cryptography. So the view
of the Crypto Panel inside IETF seems to match the views outside the IETF
as well.

The actual situation is as follows:
>

[ arguments suitable for discussion on CFRG ]

What did the Crypto Review Panel actually say about sntrup? A search
> finds
>
>
> 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. Specifically, it states:

 2. IETF participants have impersonal discussions.

      We dispute ideas by using reasoned argument rather than through
      intimidation or personal attack.  Try to provide data and facts
      for your standpoints so the rest of the participants who are
      sitting on the sidelines watching the discussion can form an
      opinion.  The discussion is easier when the response to a simple
      question is a polite answer


Please refrain from personal attacks.

Maybe I've missed some other Crypto Review Panel text on topic, but this
> doesn't appear to be "critical, objective, timely and consistent review
> of cryptographic algorithms". The failure to consider patents is a clear
> error and seems impossible to reconcile with IETF's IPR policy. It's not
> as if the patent situation is some sort of secret.
>

If you do not like the process of how IETF works, I suggest you do not try
to get an IETF code point. If you value an
IETF code point, you clearly must also value the process we have for
allocating those.


> Procedurally, I'm not sure what the right way forward is here.


There is currently no SSH Working Group at the IETF. It was requested that
one of the Security Area
Directors sponsored the draft. The Security Area Directors requested
feedback from the Crypto Panel and
outside the IETF. The result that came back was a recommendation not to
allocate a code point for NTRUprime
for the SSH protocol.

Procedurally, no one can force an AD to sponsor a document. Other pathways
to publication can be
through the appropriate IETF communities. CRFG would be one such venue, but
it seems based on
the Crypto Panel Review that CFRG would not be likely to publish this.
Another way would be via the
Independent Stream. As this stream works independently from the IETF
stream, I can not make any
statement on what the ISE would or should do. Note that normally, one would
also be able to run a BoF
leading to a Working Group, but in the case of cryptography, Working Groups
do not invent their own
cryptographic algorithms and would consult CFRG.


> Maybe the
> Crypto Review Panel should be asked to scrap this "review"


I do not see what the patent situation with Kyber has anything to do with a
code point for NTRUprime.

and evaluate the patent situation.


I do not see why it should scrap their review, simply because you do not
like the outcome. I do not see why
the Crypto Panel should review patents for Kyber when advising the Security
Area Directors and the wider
IETF on a code point for NTRUprime for SSH.

Of course, IETF and IRTF can't make decisions on
> patent validity, but IETF and IRTF _can_ observe that there are enough
> patent questions around Kyber to justify standardizing other options.
>

Kyber is not what is being discussed here. A code point for NTRUprime for
SSH was being discussed.

The SSH protocol has namespaces and  the most widely used implementation
(OpenSSH) already assigned
a code point for NTRUprime in their own namespace. This means that
proponents of NTRUprime for SSH can
already deploy NTRUprime for SSH.

As such, there is no reason to lower the IETF standards. If this had not
been possible, for instance if SSH used
integer based algorithm identifiers like TLS and IKE/IPsec, I would have AD
sponsored such a document to facilitate
deployment, as long as there was a status field associated with this
similar to TLS, IKE/IPsec and DNSSEC where
algorithms have a "Recommend" field set to NO if the algorithm did not go
through Standards Track actions. But
as said, in this case there is no need for an IETF code point to allow for
facilitating deployment.

Paul