draft-ietf-quic-tls says "QUIC requires that the first Initial packet from a client contain an entire cryptographic handshake message, which for TLS is the ClientHello."
My (possibly incorrect) understanding is this was needed so the server can, in the old QUIC/TLS embedding, statelessly send a HelloRetryRequest without having to statefully assemble a ClientHello out of multiple packets. In the new QUIC/TLS embedding, this concern no longer applies because the stateless rejects are entirely external to TLS. Thus, should we simply delete most of the #clienthello-size section?
This avoids a number of awkward pitfalls because the ClientHello size is a function of many factors, with both client and server considerations that change over time. Perhaps we add a new TLS extension or key share type and some SNIs work but larger SNIs were closer to the limit and this brings them over. Or perhaps the server's NewSessionTicket is large[*] and breaks subsequent connections from some client. Perhaps that server tested it against one client, but another client has a larger baseline ClientHello and then it breaks.
Finally, post-quantum key exchange candidates tend to come with large keys. The current text prevents QUIC from experimenting with or deploying such schemes. This is particularly fun because QUIC clients typically also speak TLS over TCP, so the security of connections to a server is bound by the weaker of TLS over QUIC and TCP.
[*] Client certificates are often inserted into the ticket, so now we have a client-specific limit being influenced by a server-specific implementation decision which is, in turn, dependent on client/CA-controlled size of client certificate. Additionally, draft-ietf-quic-transport#zerortt-parameters implies servers may wish to remember QUIC transport parameters in the ticket.
draft-ietf-quic-tls says "QUIC requires that the first Initial packet from a client contain an entire cryptographic handshake message, which for TLS is the ClientHello."
My (possibly incorrect) understanding is this was needed so the server can, in the old QUIC/TLS embedding, statelessly send a HelloRetryRequest without having to statefully assemble a ClientHello out of multiple packets. In the new QUIC/TLS embedding, this concern no longer applies because the stateless rejects are entirely external to TLS. Thus, should we simply delete most of the #clienthello-size section?
This avoids a number of awkward pitfalls because the ClientHello size is a function of many factors, with both client and server considerations that change over time. Perhaps we add a new TLS extension or key share type and some SNIs work but larger SNIs were closer to the limit and this brings them over. Or perhaps the server's NewSessionTicket is large[*] and breaks subsequent connections from some client. Perhaps that server tested it against one client, but another client has a larger baseline ClientHello and then it breaks.
Finally, post-quantum key exchange candidates tend to come with large keys. The current text prevents QUIC from experimenting with or deploying such schemes. This is particularly fun because QUIC clients typically also speak TLS over TCP, so the security of connections to a server is bound by the weaker of TLS over QUIC and TCP.
[*] Client certificates are often inserted into the ticket, so now we have a client-specific limit being influenced by a server-specific implementation decision which is, in turn, dependent on client/CA-controlled size of client certificate. Additionally, draft-ietf-quic-transport#zerortt-parameters implies servers may wish to remember QUIC transport parameters in the ticket.