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

Simon Josefsson <[email protected]> Sat, 22 Nov 2025 10:55:53 +0100

Newsgroups	gmane.ietf.saag
Message-ID	<[email protected]>

Nico Williams <[email protected]> writes:

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

There is added complexity because WG's get to chose Informational vs
StandardsTrack, and there are sometimes interactions of that decision
with IANA policies on what is required to allocate a code point.  That
interaction seems mostly unfortunate.

I think we should have code points for non-hybrid PQ algorithms.

I think we should have Informational/Experimental RFCs specifying
non-hybrid PQ in IETF protocols like TLS, SSH, etc.  They should warn
users about the dangers of non-hybrid PQ algorithms.

I think we should NOT have any non-hybrid PQ on the Standards Track or
Mandatory-To-Implement/Deply now.

Non-hybrid PQ is a clear and real security risk, and the mitigation
(hybrids) are relative low-cost.

The Informational/Experimental RFCs on non-hybrid PQ would allow us to
gain confidence in those protocols, and they could later be upgraded if
people are comfortable.

I think SLH-DSA (Sphincs+) is one candidate for where we may gain
sufficient confidence in it more quickly than other PQ algorithms.  But
implementation and deployment of SLH-DSA really needs to come before
StandardsTrack or MTI status.

/Simon

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

signature.asc (application/pgp-signature, 1.2 KB)