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

[Juho Vähä-Herttua <[e-mail]>]

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. 

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

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.


Juho