Hey all, Given store-now/decrypt-later, we should update our recommendations.
I've drafted a quick I-D which we could work on. I couldn't help myself to have my preferred outcome as a stub, but it's just a starting point. https://datatracker.ietf.org/doc/draft-westerbaan-tls-keyshare-recommendations/ Now, to actually make progress I see the following questions (if we desire to work on this): 1. Do we want to keep "Y" for quantum vulnerable algorithms? This is probably an easy one. 2. Bit harder: do we discourage ("D") or stay neutral ("N") on quantum vulnerable algorithms? Recall that "N" is defined as Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism. This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an item marked as "N" on the basis of the item having limited applicability or usage constraints. Personally I prefer D, but I can live with N if we add a comment. 3. Which post-quantum key shares do we want to recommend? There is an obvious trade off between fragmentation and hindering use cases. 3a. X25519MLKEM768. Uncontested in adoption at the moment. 3b. SecP384MLKEM1024. Higher number. Do note that we recommended P384 (at the same classical level as MLKEM768) but not P521. 3c. SecP256MLKEM768. Does it add value next to X25519MLKEM768? There are arguments about what FIPS modules or hardware is available today. Is that worth a recommendation? 3d. curveSM2MLKEM768. We did not recommend curveSM2. 3e. MLKEM{512,768,1024}. Let me cop out here and say we should consider this once we actually first adopt a document for it. My preference is to stick with X25519MLKEM768 for now. Thoughts? Best, Bas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
