On Saturday, 8 June 2024 03:53:16 CEST, D. J. Bernstein wrote:
Eric Rescorla writes:
It's important to distinguish between two senses of the word "recommend".
I'd expect the first wave of proposals to be asking the WG to say
Recommended=Y for various curve+PQ hybrids.
There will be an annoyingly large number of options on the PQ side---for
example, for different security levels and for patent avoidance---and
I'd expect a tricky discussion of which options to recommend for TLS.
I don't think it's a good idea to wait until then to figure out the
curve side. I'd like us to simplify the curve side by focusing on
X25519+PQ, just like most (I'm not saying all!) post-quantum hybrids so
far. This means saying no to brainpoolP256*+PQ, SM2+PQ, P-256+PQ, etc.
Just like we can live with Recommend=Y both for secp256r1 and x25519
(and also for secp384r1 and x448), we can live with Recommend=Y
for both P-256+PQ and x25519+PQ.
See the note above the IANA listing:
```
If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that
the item either has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use
cases.
```
P-256 and P-384 have extensive applicability and are not limited just to
the specific use of of US governmental systems.
Or to put it other way, while most clients will likely include x25519+PQ
in their key_share over anything else, omitting P-256+PQ from the
supported_groups is likely to cause interoperability issues.
Thus, that combination should be Recommend=Y. (and to hammer the point
further: X448 is Recommend=Y, and basically nobody is including that
group in key_share, we need P-256+PQ at the same place)
--
Regards,
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
