server support for MaxFragmentLength

[bobmcwhirter]

I've an embedded system with constrained resources, attempting to negotiate MaxFragmentLength extension with the server during ClientHello.

Seems rustls ignores that extension when supplied by the client, but enums.rs does acknowledge that the extension exists, along with the presence of the Fragmenter type. But it seems Fragmenter is statically configured for the server, and not on a per-connection negotiation with the client.

[djc]

Do you need that particular extension, or just something that works in the constrained environment? I was reading up on max_fragment_length and it looks like there's a newer RFC that covers similar use cases.

[bobmcwhirter]

Just something negotiable. Happy to use record_size_limit or whatnot.

…

On Fri, Mar 19, 2021 at 3:48 PM Dirkjan Ochtman ***@***.***> wrote: Do you need that particular extension, or just something that works in the constrained environment? I was reading up on max_fragment_length and it looks like there's a newer RFC <https://tools.ietf.org/html/rfc8449> that covers similar use cases. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#585 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAD4T3QI4XLWJJFKT3RKQDTEOS7XANCNFSM4ZPHCK2A> .

[bobmcwhirter]

fwiw, reading over that RFC, I see it's only in the "proposed" state. I'm still happy to go with it if we can work out those details (and I'll also continue to emit max_fragment_length for those servers that support only it).

edit: I finally was able to spot the codepoint for it:

 The "record_size_limit" extension has been assigned a code point of 28.

[ctz]

I don't think we should implement either of those extensions. There are two reasons for that opinion:

1. ecosystem implementation is patchy and broken. For example, mbedtls (very common device-side iot tls library) misimplements MaxFragmentLength so it is not able to handshake with a server that supports it^1. That is, like, obviously terrible and makes the extension a no-go. The other proposal is only that, and has no tlswg or common implementation backing.

2. you don't need it: in IoT you commonly control both ends for device-server communications, and can configure them to respect each other's limitations: this works -- at my day job we've shipped millions of iot devices using this approach.

[bobmcwhirter]

@ctz Thanks, I was unaware of (1) and do mostly agree with (2).

Mostly this just caught me out when I moved from a Java-based TLS server to rustls, and noticed the lack of support for it, which caught me out initially.

No complaints from me if closed as WONTFIX.