Martin Thomson <martin.thom...@gmail.com> writes: >I'd even go so far as to specify it: > >https://martinthomson.github.io/tls-record-limit/
Some comments... 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? (I've had support for max_fragment_length in my code since the extension was defined but it's always been commented out, no-one has ever asked for it to be supported). 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). In other words a way to say "set RecordSizeLimit to 2048 bytes but don't fragment messages", meaning the client or server holds back from sending 8,000 cipher suites and 500 extensions in the hello to keep each record below 2048 bytes. Otherwise asking for a RecordSizeLimit of 2048 might produce fragmentation, which leads to another fragment_length-induced handshake failure if your guess at what to send is wrong. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
