Here are my 5 cents: we implement this extension in our mbed TLS stack and we consider it quite important for IoT devices that have limited amount of RAM. The DTLS/TLS profiles for IoT RFC also recommends the use of this extension and we discussed this in the DICE WG and there was no objection against the recommendation.
We had also suggested to extend this functionality to make it symmetric (i.e., both the client and the server can indicate that they are facing memory restrictions). Currently, only the TLS client can indicate his restrictions with the max fragment length extension. We do, however, understand that this is not an extension that is very useful for generic Internet devices since they are typically not suffering from the same constraints. Ciao Hannes On 03/17/2017 04:49 AM, Martin Thomson wrote: > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
