On Thu, 2025-10-23 at 18:44 -0700, Jakub Kicinski wrote:
On Wed, 22 Oct 2025 10:19:36 +1000 Wilfred Mallawa wrote:
+TLS_TX_MAX_PAYLOAD_LEN +~~~~~~~~~~~~~~~~~~~~~~
+Specifies the maximum size of the plaintext payload for transmitted TLS records.
+When this option is set, the kernel enforces the specified limit on all outgoing +TLS records. No plaintext fragment will exceed this size. This option can be used +to implement the TLS Record Size Limit extension [1].
+* For TLS 1.2, the value corresponds directly to the record size limit. +* For TLS 1.3, the value should be set to record_size_limit - 1, since + the record size limit includes one additional byte for the ContentType + field.
+The valid range for this option is 64 to 16384 bytes for TLS 1.2, and 63 to +16384 bytes for TLS 1.3. The lower minimum for TLS 1.3 accounts for the +extra byte used by the ContentType field.
Sorry for not paying attention to the last few revisions.
So we decided to go with the non-RFC definition of the sockopt parameter? Is there a reason for that? I like how the "per RFC" behavior shifts any blame away from us :)
Hey Jakub,
We've made the change from record_size_limit to max_payload_len mainly because:
In the previous record_size_limit approach for TLS 1.3, we need to account for the ContentType byte. Which complicates get/setsockopt() and tls_get_info(), where in setsockopt() for TLS 1.3 we need to subtract 1 to the user provided value and in getsockopt() we need add 1 to keep the symmetry between the two (similarly in tls_get_info()). The underlying assumption was that userspace passes up directly what the endpoint specified as the record_size_limit.
With this approach we don't need to worry about it and we can pass the responsibility to user-space as documented, which I think makes the kernel code simpler.
- err = nla_put_u16(skb, TLS_INFO_TX_MAX_PAYLOAD_LEN,
ctx->tx_max_payload_len);nit: unnecessary empty line
Ah! will fixup for V9
Regards, Wilfred
- if (err)
goto nla_failure;