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

Hi, Ben,

On 24/11/25 00:50, Benjamin Kaduk wrote:
> 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).

Well, you may still publish a "Doing X is a bad idea, we strongly 
recommend against that" bluntly, without the approach of spec + 
applicability statement.



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

My comment was regarding Nico's note, specifically:
   > 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.


i.e., if a known-to-be-bad idea will be pursued, I'd rather have it 
pursued elsewhere. And if we're aware that's the case, we could very 
well put out a document why we think it was a very bad idea.


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

I simply don't think you need to register a codepoint and specifiy an 
algorithm to describe it as a bad idea. (and such criticism would 
not/could not be an "applicability statement").
Besides, what'd be the criteria for publishing one bad idea as an RFC, 
and not others?


Note: I for one I'm *not* endorsing the idea that any specific 
organization is trying to undercut the std process (I don't have the 
context or evidence to argue one way or another in this respect).

Thanks,
-- 
Fernando Gont
e-mail: [email protected]
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01

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