Re: [PATCH net-next v8 1/2] net/tls: support setting the maximum payload size

[Jakub Kicinski <kuba@kernel.org>]

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 :)