Re: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.txt

[Nikos Mavrogiannopoulos <[e-mail]>]

On Sun, Jun 13, 2010 at 11:01 AM, Juho Vähä-Herttua <[e-mail]> wrote:
> On 13.6.2010, at 11.22, Nikos Mavrogiannopoulos wrote:
>> This is not really a stopper. Since it is being negotiated it should be
>> obvious that those clients will accept the default or less. The
>> intention is to give choice to more capable clients and servers.
>
> I still don't see a big benefit in making the maximum fragment length 64kB instead of 16kB, since all implementations have to be able to fall back to the 16kB anyway, and handshake messages have maximum length of 16MB so the fragmentation has to be handled nevertheless.

I don't understand your point. Implementations that want to support
could support it (i.e. when implementing for a high bandwidth tunnel),
and others can use the 16kb limit. Being able not to use it is an
advantage not a limitation.

> The benefit of having a fragment length smaller than 2^14 seems quite clear to me. First is what Peter mentioned, the maximum TLSRecord size directly affects the required I/O buffers size that need to be allocated no matter what. Handshake message buffers still might be larger than that, but they can be allocated larger when needed and the implementation can fail gracefully if a handshake message is too large.
> Another benefit comes from DTLS, where TLSRecords themselves need to be fragmented in order to fit inside a single IP packet. If the implementation can negotiate a fragment length with a max_fragment_length extension, it doesn't have to be able to handle the double fragmentation (first fragment handshake, then encrypt, then fragment the encrypted data).

Then it shouldn't negotiate it. Isn't it obvious? The extension is for
applications that require more bandwidth and are not running on 8 or
16 bit cpus. This is an extension you use it when you need it, not
when you don't.

> If the fragment length is increased from 16kB to 64kB, I can only see a benefit of 3*(5+IV+padding+MAC) bytes per 64kB. That is at most 927 bytes with current implementations, more likely less than 200 bytes since adding 256 bytes of padding is a waste. It would save less than 0,4-1,5% of bandwidth, and if the current implementations don't implement the extension just because they have expected the value not to exceed 2^14 before, it would make all the benefits mentioned earlier void as well.
> So is your motivation behind making it larger what I just mentioned above or maybe something else? Since I would like to know if I've missed something important or if this is just a disagreement on the mentioned feature being useful or not.

The save is not on data sent but on processing speed. Decryption and
encryption today is done in hardware (several embedded systems have a
crypto coprocessor) so the bottleneck is on processing those
fragments. The larger they are the less they are processed, the higher
the bandwidth. (check what happens to ATM today with the fixed 53 byte
payload, everybody tries to do reassembly in hardware otherwise the
performance is poor. 16kb is not 53 bytes but it's close :)

regards,
Nikos