Re: [TLS] RFC 6066 - Max fragment length negotiation

[Peter Gutmann <[e-mail]>]

Martin Thomson <[e-mail]> writes:

>I'd even go so far as to specify it:
>
>https://martinthomson.github.io/tls-record-limit/

Some comments...

Firstly, do we have much real-world experience in using this extension?  From
the TLS-support matrix, it looks like very few implementations support this,
does this mean few people care about it or just that it's defined in a such a
manner that it's not practical to support it?  For anyone who does use it, how
do you use it, and what would you like to see changed?  If no fixed version of
max_fragment_length is defined, would anyone care?

(I've had support for max_fragment_length in my code since the extension was
defined but it's always been commented out, no-one has ever asked for it to be
supported).

If the draft is published, I'd like to have a boolean don't-fragment flag or
something similar available alongside RecordSizeLimit for implementations that
don't implement fragmentation (the implementation matrix doesn't record which
implementations support this, but I'd be pretty surprised if many embedded
stacks did, given the complexity and extra memory use that this adds).  

In other words a way to say "set RecordSizeLimit to 2048 bytes but don't
fragment messages", meaning the client or server holds back from sending 8,000
cipher suites and 500 extensions in the hello to keep each record below 2048
bytes.  Otherwise asking for a RecordSizeLimit of 2048 might produce
fragmentation, which leads to another fragment_length-induced handshake
failure if your guess at what to send is wrong.

Peter.