Hi Eric,
thank you for your comments. Please see inline. From: Eric Rescorla <[email protected]> Sent: 19 марта 2026 г. 23:10 To: <[email protected]> <[email protected]> Subject: [TLS] Comments on draft-wagner-tls-keysharepqc-08.txt 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, Correct. 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"). Yes, the MLS-like encoding of the length is possible and thank you for bringing it. My concern here (perhaps wrong) is middleboxes. If they don't understand new format they can drop these messages. With a separate message (after the CH or SH) they (hopefully) will ignore anything outside the CH and SH. 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 Yes, that's what the draft proposes. 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. Yes. That's what the 3rd proposal in the draft proposes, except that instead of modifying CH/SH format it negotiates the additional {large} message following them. Modifying CH/SH format is more straightforward, but see my concern about middleboxes above. 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 I agree. 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. ECH is a concern. 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. Perhaps, thank you for pointing out. Regards, Valery. -Ekr [0] Were the problem the individualized size of extensions, we could split things up between extensions. Sure we could, but it's a bit ugly.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
