Subject: [TLS] (D)TLS record size limits

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Sep 2014 10:03:18 +0200

Dear all,

when using DTLS over SCTP the message size is limited to 16KB, since DTLS
uses the same record size limit as TLS, which is 16KB. The length field in
the record layer would support up to 64KB. What is the reason for the 16 KB limit?

The reason for the question is that Diameter can be used over DTLS/SCTP and
there seems to be a use case (in mobile networks) which exceeds 16 KB,
but stays below 64KB.

With the upcoming interleaving extension, the support for large user messages
in SCTP is improved and it would even make sense for DTLS 1.3 (or so)
to support even record sizes over 64KB.
Does this "only" require a change of the record layer or are there also
some security related issues which doesn't allow to support larger messages?

Best regards
Michael

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 5 Sep 2014 11:23:25 +0300

> On 5.9.2014, at 11.03, Michael Tuexen <[email-masked]> wrote:
> 
> Dear all,
> 

As far as I know, the length is 2^14 to leave space for compression and encryption overheads, which are both 1024 bytes. Another benefit would be to keep the encryption/decryption buffers reasonable sized for constrained environments.

There has been discussions on this list about increasing the limit, but so far there has not been a valid use case for that. Seems like you would have one potential use case here.

Juho

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Sep 2014 13:12:22 +0200

> As far as I know, the length is 2^14 to leave space for compression and encryption overheads, which are both 1024 bytes. Another benefit would be to keep the encryption/decryption buffers reasonabl…
I do understand that we might want to leave some space for overhead... Regarding the limitation of receive buffers,
an implementation could use the extension
http://tools.ietf.org/html/rfc6066#section-4
to indicate this.

One could also say that the default record size limit is 16 KB, and allow to use an option similar to
http://tools.ietf.org/html/rfc6066#section-4
to negotiate a limit which is larger than 16 KB. Something like
      enum{
          2^9(1), 2^10(2), 2^11(3), 2^12(4), 2^13(5), 2^14(6), 2^15(7), 2^16-1(8), (255)
      } MaxFragmentLength;
However, supporting values larger than 2^16 would require a new record layer format with a length
field of 24 or 32 bit (or whatever). With these larger fields an appropriate extended
max_fragment_length options would be necessary.
> There has been discussions on this list about increasing the limit, but so far there has not been a valid use case for that. Seems like you would have one potential use case here.
I think use cases come from datagram oriented transport layers (UDP, DCCP, SCTP) which support fragmentation
and reassembly (which limits the list to SCTP). For DCCP and UDP, you would be limited by the path MTU, since
you want to avoid IP level fragmentation.

Best regards
Michael