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

[Martin Thomson <[e-mail]>]

On 17 March 2017 at 14:35, Peter Gutmann <[e-mail]> wrote:
> Why is it badly designed?  I can guess that some people would prefer to have a
> mechanism for client and server to debate endlessly what the most cromulent
> fragment size is, but that's about the only thing I can see.

I looked at implementing this for NSS with the idea that I would try
to be nice to embedded servers (because web servers are constrained
devices too).

I can't send a max_fragment_length extension that says I support
records of 2^14 octets in length.  Because I don't care and full-sized
fragments are valuable to me in some cases, but if a server is
constrained, it would be no trouble to send it smaller records.

And I can't fix that.  If I send a max_fragment_length extension with
a value other than the four values defined in RFC 6066, all I get for
my troubles is an "illegal_parameter" alert from any server that
implements the RFC correctly.

The design I would use is much simpler.  The extension would carry a
two octet value that is the maximum size of the plaintext that the
endpoint is willing to receive.  A client could say 2^14 and that
would allow the server to send that much if it were able.  The same
server could say 5 and the client would be forced to fragment like
crazy (ok, that last might be too far, we'd probably want to set a
lower bound on the value).

I'd happily implement and advertise that extension.