On Tue, Apr 15, 2025 at 10:33:23PM -0000, D. J. Bernstein wrote:
> Nico Williams writes:
> > there were no objections with technical reasons that were fatal to the
> > work in question
>
> I disagree. For example, the draft's regression from ECC+PQ to just PQ
> is certainly a technology issue; and this is fatal, as a contravention
> of the "improve security" goal in the WG charter.
That is more of a policy question. Does the WG want to allow pure-PQ,
yes or no?
Certainly the policy question could be fatal to this I-D if the WG were
against non-hybrid PQ. But it's not a fatal flaw in the sense of "it
could never work because you forgot about the retroencabulator
frobulating the PQ switch, which encramflobs the whole thing", which is
what I had in mind for "technical reasons".
Your objection seems to be of the "we think the retroencabulator for PQ
may fail", not "it's broken now", which is fair, but it's hard to figure
out what the likelihood of that is. Framing this as a policy question
means not having to think too much about the likelihood of ML-KEM
falling to cryptanalysis.
The WG should decide the policy question before deciding to work on this
or any other non-hybrid.
> The draft might be able to escape this if it were serving other goals in
> the charter, but it's not as if the draft lays out a case for that. The
> draft says non-hybrids are important for users who demand non-hybrids;
> this is a circular argument. To the extent that this is an allusion to
> NSA purchasing, it violates BCP 188 ("IETF Will Work to Mitigate
> Pervasive Monitoring").
It might be fine to adopt this only for publication as Experimental.
Adopting this I-D before deciding the policy question and the related
which-track question seems wrong to me -- possibly an end-run around the
[predictable, earlier?] objections.
> > The policy question, if called, could in principle lead to the IETF
> > asking the ISE not to publish this work.
>
> Here I agree, and I think this would be a good way forward.
It's really just a policy question. That should be decided before the
adoption question.
Nico
--
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
