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/eb3c9febfa9969792b8ac0ca56ee9fbd9b0bd7ee/lib/ext/record_size_limit.c#L104-106 > > So I have a slight preference for not being tied to a (kind of > confusing) RFC.
Alright :)
