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

[Martin Thomson <[e-mail]>]

On 17 March 2017 at 21:38, Peter Gutmann <[e-mail]> wrote:
> 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?

This is apparently a big deal for people building little things with
TLS in them.  Hannes knows better than I do.  On the web, this
extension basically doesn't exist (for the aforementioned reasons, in
part, also because browsers historically didn't much for servers and
their resource constraints).

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

TLS 1.3 has an issue here in that it encrypts handshake messages, and
that includes the worst offender (Certificate).  You might not care
about 1.3, but I think that handshake fragmentation is just something
implementations will need to deal with there.

Plaintext records don't have any such limits.  I explicitly excluded
them.  That means that TLS 1.2 implementations shouldn't be affected.
Well, unless they wanted to send massive messages after the handshake
completes.  Renegotiation would do that, of course, so don't do that.