On Thursday, 21 November 2024 22:02:45 CET, Stephen Farrell wrote:
Hiya,
Without going into the details, I'm generally sympathetic to djb's
argument here, but also do recognise ekr's "we allow anyone to get
a RECOMMENDED=N code point" as valid.
That said, if the WG adopt *anything* with RECOMMENDED=Y in this
space (incl. for KEMs) then I think the onus is on the WG to write
down guidance for the entire space, especially as there will be
codepoints for non-hybrids.
In summary: I don't think we should go back to previous policies
where we'd try prevent registration of non-hybrids, but I do think
we really need to try reach consensus on guidance text for the whole
slew of PQ possibilities for TLS. (And IMO that guidance would be
along the lines of djb's argument.)
As somebody wishing promt publication of the "pure ML-DSA in TLS" RFC,
I'm also in favour of the TLS WG publishing a BCP that marks those
codepoints as "MAY" or even "SHOULD NOT", with a detailed information
why depending on pure algorithms, until we know that at least one of them
is thoroughtly broken, may not be a good ieda.
Cheers,
S.
PS: It seems pretty ironic to me that ambiguities in NIST and NSA text
are turning out such a barrier to getting PQ stuff done when at the
same time they're some of the entities trying to (again IMO) rush a
pile of things here. (To be clear: for me, everything PQ except hybrid
KEMs is a thing for which we ought hasten much more slowly.)
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
