Subject: [TLS] custom lower limit of record_size_limit

From: Daiki Ueno <[email-masked]>
Date: Sat, 19 Jan 2019 09:02:43 +0100

Hello,

While RFC 8449 defines the minimum of record_size_limit as 64, if a
server takes account of the Security Consideration and chooses its own
lower limit (larger than 64), what should it behave?

   Very small record sizes might generate additional work for senders
   and receivers, limiting throughput and increasing exposure to denial
   of service.

In the beginning of section 4 (emphasis is my own):

   When the "record_size_limit" extension is _negotiated_, an endpoint
   MUST NOT generate a protected record with plaintext that is larger
   than the RecordSizeLimit value it receives from its peer.

and later in the same section:

   Endpoints SHOULD advertise the "record_size_limit" extension, even if
   they have no need to limit the size of records.  [...] _For
   servers, this allows clients to know that their limit will be
   respected._

My interpretation is that, if the client sent "record_size_limit" but
didn't receive the extension from the server, that would mean the
extension was not negotiated and the server may not respect the limit.

Is this correct, or 64 is really mandatory to implement?

Regards,
-- 
Daiki Ueno

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 16:13:47 +1100

> Is this correct, or 64 is really mandatory to implement?

Unfortunately, if you want your peer to respect your limit, then you have to be willing to generate very small records.

BTW, 64 is entirely an arbitrary number.  It's at the point where the overheads get really noticeable, so performance is probably pretty bad well before you get to this point.  But we didn't get any indication that it was impossible to go that low.

If there had been feedback about it being too small, I'm fairly sure that a large number would have been fine.  Do you know why 64 is considered too hard to implement?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 21 Jan 2019 09:03:13 +0100

On Mon, 2019-01-21 at 16:13 +1100, Martin Thomson wrote:
> Unfortunately, if you want your peer to respect your limit, then you
> have to be willing to generate very small records.
> 
> BTW, 64 is entirely an arbitrary number.  It's at the point where the
> overheads get really noticeable, so performance is probably pretty
> bad well before you get to this point.  But we didn't get any
> indication that it was impossible to go that low.
> 
> If there had been feedback about it being too small, I'm fairly sure
> that a large number would have been fine.  Do you know why 64 is
> considered too hard to implement?

I do not think that 64 is not hard to implement, but I think it is very
hard to implement it in a way that it is efficient. I have not measured
specifically TLS with 64 byte packets, but my experience with ATM
(telephony) which has 53-byte packets, suggest to avoid small
packetizations if you want use your CPU for something other than
packing and unpacking frames.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jan 2019 08:33:49 +1100

On Mon, Jan 21, 2019, at 19:03, Nikos Mavrogiannopoulos wrote:
> hard to implement it in a way that it is efficient. 

Totally agree.  There's like a curve for performance with an asymptote as records get bigger and a steep incline as records get smaller.  I picked 64, not because it is good - it's clearly terrible for performance - but because it was a power of 2 that was enough bigger than the handshake overhead that you couldn't configure a connection that was guaranteed to be unusable.  32 might have been enough, but it's pretty ludicrous, especially in DTLS.

I didn't want to make this a performance consideration.  Clearly 128 is much better than 64 performance-wise, but then 256 is better again.  Where on that curve your preference lies will depend on your constraints.  In the end, if a peer wants 64 and that would degrade performance too much for you, then you have a choice: don't negotiate the extension, or - for clients that don't get this choice - don't communicate with that peer.