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

[Joseph Birr-Pixton <[e-mail]>]

On 18 March 2017 at 09:36, Peter Gutmann <[e-mail]> wrote:
> Joseph Birr-Pixton <[e-mail]> 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