Re: [saag] SSH & Ntruprime

[Paul Wouters <[e-mail]>]

On Mar 26, 2024, at 08:49, Simon Josefsson <simon=[e-mail]> wrote:

> * OpenPGP -- the crypto-refresh draft had early implementations that
>  were deployed and the draft later changing, leading to having to bump
>  code point allocation leading to the v4 vs v5 vs v6 community
>  fracture.

This was more subtle. An author continued updates after the WG closed. That author also made changes to their implementation that had the draft code points originally behind a non-default —draft option. By changing that code, it modified their meaning of “deployed in the wild”. That is, code was modified to argue about draft code point stability. This draft was then forked and basically squatted the code point with modifications explicitly against the WG consensus. The WG decided to bump its own (re-opened WG and updates draft) packet version number to avoid future internet interoperability issues on the squatted code point.

> For SSH there has been repeated poor communication between the SSH
> implementer community and the IETF community, each side effectively
> accusing the other of acting on bad faith and going down their own road.
> I don't think this thread will improve that situation -- on the contrary
> -- but it gives an illustration that there are still valid reasons for
> this lack of co-operation, with people in the IETF acting to exclude
> contributions.  I believe the quality of future SSH improvements in the
> IETF is negatively affected as a result, with Internet users everywhere
> hurt as a consequence.

SSH has always been a bit special in this case. If there was good community cooperation, not a community forced to follow its main implementerion, we would have an active SSH WG. But a main implementation cannot expect to drop drafts off at the IETF for rubber stamping.

Luckily (or perhaps by design, this predates me), the SSH code points have string identifiers allowing for implementations to create and maintain their own code points that do not clash with IETF consensus based code points.

To steer this back on topic, if an SSH implementation wanted a code point for the Ietf namespace that used CBC, I think there would be a clear consensus not to do this for security reasons. With this NTRUprime case, we have a less clear example. 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.

If the algorithm namespace had been less flexible and not used namespaces, and some private use number had been used for this and we now saw a large deployment, as SEC AD i would have been in favour of documenting this with an Informational RFC.

If this had used an (now expired or lingering) draft with (early code point) allocations within the IETF space, I would have been in favour of finishing the draft as informational RFC, including the note of the Crypto Panel in the document.

But in this case, everyone who wants to is using the @openssh.com code point without causing interop issues, so as SEC AD, I didn’t see a strong reason for a new (sort of duplicate) allocation in the ietf namespace. It would not lead to removal of the @openssh.com code point in implementations (due to wide deployment) and arguably lead to more complications supporting two code points for the same thing. And would give outsiders a way to argue that the IETF actively adopts and supports this algorithm, even though the IETF Crypto Panel did not do so.

That is to say, I do not think the IETF is “acting to exclude contributions” or “hurting internet users everywhere”.

Paul