Re: [TLS] record layer limits of TLS1.3

> On 23 Nov 2016, at 09:50, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> 
> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> 
>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote:
>>> Hi, Nikos
>>> 
>>> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <nmav@redhat.com>
>>> wrote:
>>> 
>>>> 
>>>> Hi,
>>>>  Up to the current draft of TLS1.3 the record layer is restricted
>>>> to
>>>> sending 2^14 or less. Is the 2^14 number something we want to
>>>> preserve?
>>>> 16kb used to be a lot, but today if one wants to do fast data
>>>> transfers
>>>> most likely he would prefer to use larger blocks. Given that the
>>>> length
>>>> field allows for sizes up to 2^16, shouldn't the draft allow for
>>>> 2^16-
>>>> 1024 as maximum?
>>> 
>>> I am not opposed to this, but looking at real browsers and servers, 
>>> we see that they tend to set the size of records to fit IP packets. 
>> 
>> IP packets can carry up to 64kb of data. I believe you may be referring
>> to ethernet MTU sizes.
> 
> I’m referring to the IP packets that they actually use, and that is set by TCP to fit the PMTU, which is <= the ethernet MTU.  In practice it is 1500 bytes for most network paths.
> 
>> That to my understanding is a way to reduce
>> latency in contrast to cpu costs. An increase to packet size targets
>> bandwidth rather than latency (speed).
> 
> Sure, but running ‘openssl speed’ on either aes-128-cbc or hmac or sha256 (there’s no test for AES-GCM or ChaCha-poly) you get smallish differences in terms of kilobytes per second between 1024-byte buffers and 8192-byte buffers. And the difference going to be even smaller going to 16KB buffers, let alone 64KB buffers.
> 
>>> The gains from increasing the size of records from the ~1460 bytes
>>> that fit in a packet to nearly 64KB are not all that great, and the
>>> gains from increasing records from 16 KB to 64KB are almost
>>> negligible. At that size the block encryption dominates the CPU time.
>> 
>> Do you have measurements to support that? I'm quite surprized by such a
>> general statement because packetization itself is a non-negligible cost
>> especially when encryption is fast (i.e., in most modern CPUs with
>> dedicated instructions).
> 
> As long as you run over a network that has a smallish MTU, you’re going to incur the packetization costs anyway, either in your code or in operating system code. If you have a 1.44 GB file you want to send, it’s going to take a million IP packets either way and 100 million AES block operations. 
> 
> Whether you do the encryption is a million 1440-byte records or 100,000 14,400-byte records makes a difference of only a few percent.
> 
> Measurement that we’ve made bear this out. They’re with IPsec, so it’s fragmentation rather than packetization, but I don’t think that should make much of a difference.
> 
> Again, I’m not opposed to this. A few percent is a worthy gain.
OK. However it would be useful to have the possibility to use a larger record than 16 KB. This is not relevant
when using TLS over TCP for which the application does not expect record boundary preservation. For DTLS the
story is different. The application expects record boundary preservation. Therefore the maximum DTLS record
size does limit the maximum message size the application can transfer. In the case of DTLS over UDP, this
is not so critical as long as you avoid IP fragmentation and have MTUs smaller than 16 KB. However, in the
case of DTLS over SCTP this imposes a limitation. SCTP does segmentation and reassembly and therefore the
MTU limit does not apply. Diameter is a protocol possibly using DTLS/SCTP as its transport and I was
told that the 16 KB limit is a real restriction in some cases, relaxing it to 64 KB would be fine for them.

So I'm not saying we need to change the default to 64 KB, we can put it wherever you find appropriate, as
long as both sides can negotiate a larger limit.
For example, one could allow the Maximum Fragment Length Negotiation to negotiate a value larger then 16KB.
You would only need to extend the enum in
https://tools.ietf.org/html/rfc6066#section-4
to allow values larger than 2^14.

Best regards
Michael
> 
> Yoav
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls