It can still be experimental right?
On Fri, 20 Mar 2026, 08:59 Blumenthal, Uri - 0553 - MITLL, <[email protected]> wrote: > David Benjamin nailed it. > > McEliece can be used only if its public keys are pre-shared. It is not > suitable for dynamic key exchange. > — > Regards, > Uri > > Secure Resilient Systems and Technologies > MIT Lincoln Laboratory > > On Mar 20, 2026, at 00:14, Loganaden Velvindron <[email protected]> > wrote: > > > I would be in favor of adoption. Always good to have backups. On Fri, 20 > Mar 2026, 00: 11 Eric Rescorla, <ekr@ rtfm. com> wrote: Document: > draft-wagner-tls-keysharepqc-08. txt Thank you for sending this draft. I am > ambivalent on whether it > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside the Laboratory. > > ZjQcmQRYFpfptBannerEnd > I would be in favor of adoption. Always good to have backups. > > On Fri, 20 Mar 2026, 00:11 Eric Rescorla, <[email protected]> wrote: > >> Document: draft-wagner-tls-keysharepqc-08.txt >> >> Thank you for sending this draft. >> >> I am ambivalent on whether it is actually important for TLS to support >> PQ algorithms with keys > 64KB. I think it's clear that the >> performance implications would be quite bad in many cases (e.g., the >> Web), though perhaps there are some environments where it doesn't >> matter. I understand people might be concerned about ML-KEM, but there >> are other alternative PQ algorithms that do not have quite so dire >> performance properties. >> >> However, if we are to do so, I do not believe that any of the >> proposals you have here work very well. As you note in your >> introduction, there are two size limits in play here: >> >> 1. The maximum size of a HandshakeMessage (2^24-1) >> 2. The maximum size of an extension (2^16^1) >> 3. The maximum collective size of all the extensions (also 2^16-1) >> >> I don't think that the HandshakeMessage size is really relevant, as >> algorithms with keys that exceed 16MB are not likely to be >> practical. The basic problem here is the maximum collective size of >> the extensions [0]. As a result, it is simply not possible for a >> client to transmit more than about 64K of material in its initial >> ClientHello and also have it be compatible with existing servers. IMO, >> the right approach is to address this head-on, as follows: >> >> 1. Modify the ClientHello format to remove the limit. >> 2. Have a way for the client to learn it can use the new ClientHello >> format. >> >> The fix for (1) is straightforward: replace some if not all of the >> variable-length vectors with fixed limits with ones with >> variable-length limits as in MLS's `T<V>` syntax (see RFC 9420 S >> 2.1.2). Once you have done this, then you can just naturally carry >> arbitrarily large extensions. We can discuss whether this would be a >> global replacement (all vectors) or a targeted one >> ("large_extensions"). >> >> The first of these is obvious, so let's focus on the second. The >> natural way to do this is with HRR. In particular, the idea would be >> to create a new extension that indicated that you supported the new >> format. For concreteness, say we use the "large_extensions" extension, >> which just redefines Extensions as: >> >> struct { >> ExtensionType extension_type; >> opaque extension_data<V>; >> } Extension; >> >> and then the various extensions fields as: >> >> Extension extensions<V>; >> >> The semantics of the large_extensions extension are that the client >> offers it and if the server accepts it, future messages use the new >> format. The resulting handshake looks like this (with some fields >> elided): >> >> Client Server >> >> ClientHello >> + large_extensions >> + supported_groups[X25519, McEliece] >> + key_share[X25519] --------> >> >> HelloRetryRequest >> + large_extensions >> + supported_groups[McEliece] >> >> >> ClientHello (large extensions version) >> + large_extensions >> + supported_groups[X25519, McEliece] >> + key_share[McEliece] --------> >> >> ... >> >> This fits naturally into our existing pattern and reflects the fact >> that you can't safely send the big key share in the first message >> anyway, and you most likely don't want to if you don't know the other >> side supports it because it's a waste of bandwidth. Moreover, because >> it's a generic solution, you don't need to change anything else. >> >> It's slightly irritating that even if you know that the server >> supports large extensions you can't just start out with that. I think >> that's a problem we could figure out how to solve if we really had to, >> but TBH I doubt it's worth it because you're already absorbing >> a bunch of round trips. It *might* be worth it for ECH, but I'd >> want to see some evidence that ECH was really going to exceed 64K. >> >> As an aside, I think the material in S 3.1.1 about changing >> PskKeyExchangeMode >> is misguided. The right approach is just to treat these PQ algorithms >> as if they were DH and overload psk_dhe_ke. >> >> -Ekr >> >> >> [0] Were the problem the individualized size of extensions, we could >> split things up between extensions. >> >> >> >> _______________________________________________ >> 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] > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
