On Mon, 27 Oct 2025 12:32:02 +0100 Sabrina Dubroca wrote:
But we haven't managed to avoid that completely:
- if (value < TLS_MIN_RECORD_SIZE_LIM - (tls_13 ? 1 : 0) ||
We could, by taking a smaller minimum payload size than what the RFC says (anything that allows us to make progress, maybe 8B?). ie, I don't think we have to be as strict as rfc8449 (leave the userspace library in charge of rejecting bogus values during negotiation of this extension).
I understand the motivation, the kernel code is indeed simpler.
Also more consistent: the kernel syscalls work with record payload (at the send()/recv() level). The rest is hidden. Userspace could try an approximation by sending max_payload-sized chunks with MSG_EOR.
Last night I read the RFC and then this patch, and it took me like 10min to get all of it straight in my head.
I don't find this stuff very clear either tbh, but maybe that's a problem in the RFC itself.
Maybe I was tried but I feel like the user space developers will judge us harshly for the current uAPI.
But userspace libraries have to do the same computations on their side if they want to implement this RFC. They have to figure out what the max payload size is as they're building the record, they can't just chop off a bit at the end after filling it.
Quick grepping through gnutls got me to this: https://gitlab.com/gnutls/gnutls/-/blob/eb3c9febfa9969792b8ac0ca56ee9fbd9b0b...
So I have a slight preference for not being tied to a (kind of confusing) RFC.
Alright :)