Dear Bas,
This is a great document! I have read it in its entirety and I support
it fully. Thank you for taking this important initiative.
Regarding your questions:
1. No (as you suggest, this is an easy one.)
2. I also prefer D.
3. Seems like X25519MLKEM768 should be the recommendation, no?
Thanks again,
Nadim Kobeissi
Symbolic Software • https://symbolic.software
On 2/23/26 3:18 PM, Bas Westerbaan wrote:
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/ <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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
