Re: [saag] SSH & Ntruprime

[Watson Ladd <[e-mail]>]

On Thu, Mar 28, 2024 at 4:45 AM Paul Wouters
<paul.wouters=[e-mail]> wrote:
>
> 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.

Please show up to an NTP WG meeting sometime. *smuggles in popcorn*.
Are there other SSH implementations that actively want an IETF WG and
feel locked out, or is this a matter of it works well enough that the
industry is not putting resources behind another implementation? If we
have the OpenSSH developers and no one else in a room at an IETF, are
we really adding anything?

>
> 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.

I've not seen CBC, but I have seen plenty of bad cryptographic choices
get IETF consensus despite better alternatives even recently (HTTP
Signatures anyone?). We continue to think primitives are enough, and
ignore protocol design issues with the delusion that the people
designing the protocols understand how to do it. The case of TLS 1.3
is really unusual still.

>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.

There is no IETF crypto panel. There's an IRTF one. And it's very much
news to me that the IRTF Crypto Review panel can block things: that's
at odds with what I've heard to be the guiding philosophy of rough
consensus and how the CFRG has functioned (not that the current state
is a model). I think the idea that we are endorsing a closed book of
primitives has made for some very bitter and ugly fights, slowed down
the pace of important work, and really ignores the way these things
actually play out.

If we'd decided to not follow NIST, I think we would have seen a lot
of pressure to make ML-KEM based drafts given the need for them from a
lot of people.

Sincerely,
Watson