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

On Sun, Nov 23, 2025 at 12:19:18PM -0300, Fernando Gont wrote:
> On 22/11/25 00:44, Benjamin Kaduk wrote:>>
> > > However, that's not my understannding of how things are supposed to work:
> > > IETF RFCs represent IETF consensus. And if something is known and understood
> > > to be a bad idea, I do think that the IETF shouldn't work on that. If
> > > anything, it's better that such work is carried out elsewhere, rather than
> > > having bad ideas rubber-stamped by the IETF "because they would otherwise be
> > > pursued elsewhere, anyway".
> > 
> > If the IETF writes the RFC, we can put an applicability statement on it
> > with prominent warnings that it's a bad idea outside of a certain
> > situation.  I'm willing to believe that there are some cases (not all)
> > where having control over that warning statement provides value to
> > outweigh the cost of appearing to give the bad idea IETF imprimateur.
> 
> I strongly disagree. What you seem to be suggesting is that any idea that is
> believe to be pursued here or there should be published as an RFC.

I'm going to assume that you're disagreeing with the existence of cases
where the value of writing commentary about a document outweighs the cost
of appearing to give the bad idea the IETF imprimateur (rather than, say,
our ability to put an applicability statement in a document we publish).

I'm having a hard time seeing how you go from there to a conclusion that
any idea that is going to be pursued anywhere should be published as an
RFC.  I specifically said "not all" in my initial remark, and will now go
further and say that I expect it to be a rare occurrence.

> Having known-to-be-bad ideas be pursued simply because "they would otherwise
> be pursued elsewhere" seems bad on so many different fronts:

Yes, which is why I did not propose doing so.

> * I believe it affects the credibility of other RFCs.
> 
> * Wastes the resources of the IETF community, because now the community
> needs to waste time on known-to-be-bad ideas.

Perhaps we should return to the specific example at hand.  Some people
(IIUC, DJB and Nico at least) seem to be saying, or at least suggesting as
a possibility, that the NSA is trying to undercut the standards process
(ignoring for the moment that nobody is proposing to put non-hybrid PQC for
TLS on the standards track) by publishing non-hybrid PQC as an RFC and
pushing companies to implement it/make it on by default/etc.  Suppose that
is true, and that we have IETF consensus to oppose non-hybrid PQC for TLS.
What is the best action the IETF can take in that scenario?  I see at least
three options: (1) do nothing/publish nothing, letting the codepoints get
registered in some non-IETF manner and making the NSA have to use different
pressure to get the keyex algorithms widely implemented; (2) let the
codepoints get registered in a non-IETF manner but publish an RFC with our
concerns and critique of the situation; and (3) publish the same
critique/concerns from (2) but attaching that RFC to the codepoint
registrations in question.

In (3), anyone who actually attempts to look up the algorithm in the
registry finds our concerns right away ... in (2), they might be a lot
harder to find.  Do you think it is impossible to write the RFC in (3)
without endorsing the algorithm itself?  I think that it would be pretty
straightforward to do so.

-Ben

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