Hiya,
Answering a few points at once: On 15/12/2024 17:05, Eric Rescorla wrote:
I don't think it's a good use of the WG's time to put out this kind of guidance statement. Rather, we should simply adopt some subset of the proposed drafts. The Recommended column in the code point registry serves as the TLS WG's recommendation.
I don't think that mechanism is quite sufficient here, for at least two reasons: 1) if we e.g. add recommended=y for X25519MLKEM768, that'd mean we now have 5 such groups all with recommended=y so we're still missing guidance required amongst those which becomes a thing we do care about whereas we more or less didn't when we only had 4. 2) if someone can do X25519MLKEM768, then they can also do MLKEM768 which (let's assume) remains recommended=n, so we ought give such folks guidance to not turn that on (if we end up with consensus to say that). Additionally, all the sigint agency noise is, I'd guess, a cause of confusion that we might be able to help reduce for (some of) the vast majority of e.g. web sites/mail servers who do not have to pay attention to hybrid-hate or brainpooling. On 15/12/2024 17:51, Tim Bray wrote:
But I think it would be of great help to the community of crypto customers like me if a document starting with something like Stephen’s draft could be expanded a bit to outline the state> of play, including the interesting lack of consensus among experts and across the intel community, and published.
I'd argue to keep discussion in this doc to the absolute minimum. There's the pquip WG who exist to document the arguments (or at least that's what I'd like to see 'em doing, rather than being all positive about everything PQ;-) On 15/12/2024 17:56, Salz, Rich wrote:
If that draft is useful, it probably belongs in the UTA working group, not TLS.
I don't care. If this does go somewhere, I would prefer not to have to do a pointless dispatch-dance. The TLS WG seems better to me as this issue is not application-specific.
I would express the guidance this way: Use a hybrid that combines PQ and “classic” algorithms, so that if one is broken you’re still safe. If you are required to use only PQ, so be it.
The latter set of people/applications would not benefit from our help, so my take is, for the purposes of this document, we should ignore 'em and not keep having the sigint tail wag the worldsized dog. Cheers, S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
