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

From: Joseph Birr-Pixton <[email-masked]>
Date: Sat, 18 Mar 2017 09:17:31 +0000

On 17 March 2017 at 16:01, Hannes Tschofenig <[email-masked]> wrote:
> Here are my 5 cents: we implement this extension in our mbed TLS stack

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.

When I came across this a year or so ago, I concluded that nobody
could have actually deployed max_fragment_length using mbedtls.

Cheers,
Joe

[1] https://github.com/ARMmbed/mbedtls/issues/387

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 18 Mar 2017 09:36:05 +0000

Joseph Birr-Pixton <[email-masked]> writes:

>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?  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.

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.

Peter.

---

From: Joseph Birr-Pixton <[email-masked]>
Date: Sat, 18 Mar 2017 10:18:03 +0000

On 18 March 2017 at 09:36, Peter Gutmann <[email-masked]> wrote:
> What's the largest handshake message it sends?

In my case, a KB or so of client certificate.

> I would assume that for at

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.

> consumption while being large enough to not have to worry about fragmenting

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Mar 2017 20:29:59 +1100

> consumption while being large enough to not have to worry about fragmenting

No matter how much of a good idea that is, you would risk handshake
failure by doing so.  Compliant server implementations are required to
send an "illegal_parameter" alert if you send that.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 19 Mar 2017 10:58:34 +0100

Hi Joe,

thanks for pointing this out. I will talk to our mbed TLS team to find
out what the status of this issue is.

Ciao
Hannes

On 03/18/2017 10:17 AM, Joseph Birr-Pixton wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Mar 2017 15:54:57 +0100

Hi Joe,

> as required by the spec. Attempts to use it with a conforming peer

while I am waiting for my mbed TLS coworkers to respond I have been
asking myself what the MFL extension of handshake message can really
provide. For example, the certificate message is typically one of the
largest messages in the TLS handshake. If it is too large to fit in a
buffer of the client then what should be done? As a client I cannot
verify just half of a certificate. Of course, if it possible to avoid
sending a long certificate chain but this is subject to deployment choices.

While I can see some use of the MFL extension in the handshake protocol,
for example, in the selection of the ciphersuite or in deciding whether
multiple messages should be concatenated into a single datagram I fear
there is typically much less room for maneuver compared to the
application layer protocol.

Ciao
Hannes