On 17 March 2017 at 21:38, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > 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?
This is apparently a big deal for people building little things with TLS in them. Hannes knows better than I do. On the web, this extension basically doesn't exist (for the aforementioned reasons, in part, also because browsers historically didn't much for servers and their resource constraints). > 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). TLS 1.3 has an issue here in that it encrypts handshake messages, and that includes the worst offender (Certificate). You might not care about 1.3, but I think that handshake fragmentation is just something implementations will need to deal with there. Plaintext records don't have any such limits. I explicitly excluded them. That means that TLS 1.2 implementations shouldn't be affected. Well, unless they wanted to send massive messages after the handshake completes. Renegotiation would do that, of course, so don't do that. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
