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

[Peter Gutmann <[e-mail]>]

Martin Thomson <[e-mail]> writes:

>In this case, max_fragment_length is so badly designed that you can actually
>argue that it has utility, but I don't consider that as a good argument for
>the general case.

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.

As a slight aside, the client-only nature of the extension seems to be another
example of the all-the-world's-the-web view of TLS, that servers have infinite
resources and it's clients who may be constrained.  In the embedded world it's
far more likely to be the exact opposite, the server (e.g. a PLC) is very
resource-constrained and the client connecting to it (e.g. a PC controller)
has all the resources it needs.

Incidentally, here's a picture of a $25 million web server:

http://www.abb-conversations.com/wp-content/uploads/2013/09/ABB_Phaseshifter_transformer.jpg

It's resource-constrained.

(Actually that one doesn't do SSL as far as I know, and the server runs NT 4).

Peter.