On 18 March 2017 at 09:36, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Joseph Birr-Pixton <jpix...@gmail.com> writes: > >>With the greatest of respect, mbedtls *doesn't* implement >>max_fragment_length[1], because it doesn't fragment handshake messages as >>required by the spec. Attempts to use it with a conforming peer will fail to >>handshake. > > What's the largest handshake message it sends?
In my case, a KB or so of client certificate. > I would assume that for at > least the larger fragment sizes it'd be OK, because no handshake message would > get large enough to require fragmentation. True. Personally I was interested in the 512 byte max_fragment_length, because this is the best match for devices with the minimum IP MTU of 576 bytes. As a server, that breaks sending really any kind of certificate chain. As a client, it breaks client auth for similar reasons. > Incidentally, has anyone else who's implemented this dealt in the weird > omission of 8K by using the logical value 5 that follows 1, 2, 3, 4 for 512, > 1K, 2K, and 4K? In many cases 8K is just what you need, it halves memory > consumption while being large enough to not have to worry about fragmenting > handshake messages. Mmm, that is a strange omission. Personally I think this extension's encoding of the available lengths is too much policy and not enough mechanism. For want of an extra byte! Cheers, Joe _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
