>X25519MLKEM768 should be ranked higher than X. What is X? Agree that this does not make sense. I think the reasonable thing with X25519MLKEM768 it to make it MTI. That makes sense given that Cloudflare report 70% use in CHs.
>client should rank PQ keyshares higher than non-PQ shares. Yes please. >But that would mean ranking some recommended=N keyshares higher than >recommended=Y shares. I think that just illustrates how broken the RECOMMENDED mechanism is. > Do we need to say anything about HRR? Should a server HRR when the client > sends a non-PQ share, but it and the server do support a PQ share? Yes, I think the server should try to get a PQ shares. (Should be “when the client does not send a PQ share", as the client might not send a share in CH) Cheers, John Preuß Mattsson From: Bas Westerbaan <[email protected]> Date: Thursday, 30 April 2026 at 11:11 To: Bellebaum, Thomas <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] Re: Working group adoption call for draft-westerbaan-tls-keyshare-recommendations-02 I would be happy about a recommendation of hybrids over these curves in text form (e.g. "Clients and servers SHOULD rank X25519MLKEM768 higher"), if this is easy to embed in the process chosen to adopt this document's change. I like the idea and started to draft a PR, but figuring out the actual wording is not that straightforward. 1. X25519MLKEM768 should be ranked higher than X. What is X? All other (future) keyshares? Listing the non-PQ recommended=Y keyshares explicitly? The most direct advise would be that client should rank PQ keyshares higher than non-PQ shares. But that would mean ranking some recommended=N keyshares higher than recommended=Y shares. 2. Do we need to say anything about HRR? Should a server HRR when the client sends a non-PQ share, but it and the server do support a PQ share? Best, Bas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
