On 17 March 2017 at 14:35, Peter Gutmann <pgut...@cs.auckland.ac.nz> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
