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]
