[saag] Re: on derivative work rights statements in emails to Security Area mailing lists

On Fri, Nov 21, 2025 at 01:49:37PM -0800, Christian Huitema wrote:
> I think this boils down to an argument about power and authority of the
> IETF. [...]

As we often say: there is no IETF protocol police.

We can -and do- say no to some things, it's just not the same thing as
being an enforcer of "thou shalt not do X".

The specific disagreement I was referring to was about whether a WG
should adopt a given work item.  I think DJB thought that by not
adopting it the work wouldn't get done.

My point to DJB is that because the necessary codepoints have been
assigned (and would have been even if the WG did not want it, short of
doing the work of closing the registry) the WG cannot block that work.
We only get to decide whether that work will be done "in the WG" or
outside the WG, and if it's going to get done, then it's better to do it
"in" the WG than outside it.

It's important that DJB understand this point.  The WG chair really did
no one dirty on that decision.  Thus in that particular case there were
no grounds to appeal.  This sub-thread I started is really an attempt to
get this point across in a way that hopefully soothes the seas rather
than roiling them.

That we will end up with noon-hybrid PQ available sooner than is wise is
unfortunate, but that is not the result of a WG chair's poor judgment,
not anything even more sinister.  As long as they are not must-use or
must-implement, I think we can still make the Internet safer for its
users.

One might look back at how the registries ended up so open and wonder if
there was some sinister play there.  I doubt it.  Anyways, we do not
have a time machine.  And as you note we do have a long tradition of
letting national agencies get codepoints for their recommendations.

We probably have the most "moral", but least _actual_, authority when we
push back against national agencies that seek to enable policies we
dislike (as I tried to the other day on this same list).  They have guns
and the credible claim to authority to use said guns, and we don't.

>   ... Should the working groups act as gatekeeper and use their authority to
> "absolutely not allow" deployment of algorithms that they find inappropriate
> for the Internet? That would mean, of course, instructing IANA that only
> algorithms approved by Working Groups should be allocated code point. The

Right, indeed.

> problem with that is whether the IETF has enough moral authority to make
> such decisions stick. Sometimes it does -- see for example the rejection of
> various proposals to weaken encryption in TLS. [...

We have definitely had cases of codepoint camping in various namespaces
over the years.  I can name a few cases.

Ergo: the IETF lacks the tools, and therefore the authority, "to make
such decisions stick".  But as you say, sometimes it has the "moral
authority".

I say this would have been a case where the IETF should have attempted
to use its moral authority _but for_ the fact that the ship sailed
already.  I disagree with DJB as to how to get the horse back into the
barn: I say we can't, so don't try.

> That's why I personally think that the IETF should concentrate on making
> sure that safe algorithms can be easily deployed, rather than attempting to
> use the IANA as a gatekeeper. In the particular dispute between hybrid and
> non-hybrid, that means publishing and endorsing a good hybrid solution.

+1, with the very slight caveat above.

> By the way, the debate is not just about hybrid versus non hybrid. There is
> also a debate about how much deference the IETF should have to NIST. If we
> end up only recommending the technologies that NIST approved, then NIST
> becomes a single point of failure. Maybe we are OK with that because there
> are no credible alternative. Or maybe not.

This is why we have CFRG.  We don't only "bless" NIST recommendations.
Other nation's equivalents to NIST also have at times asked for and
gotten theirs.

Nico
-- 

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]