As is well known, the RFC6066 maximum_fragment_length (MFL) extension has a
few serious deficiencies, that led to its subsequent deprecation in
favour of RFC8449 record_size_limit (RSL).
Nevertheless a number of TLS implementations still support MFL, and
there is some history of completeness/correctness issues. One
particular aspect of the specification seems unclear to me.
https://datatracker.ietf.org/doc/html/rfc6066#section-4
...
The negotiated length applies for the duration of the session
including session resumptions.
...
It seems to me that as a consequence:
- The initially negotiated value is implicitly still in force
after resumption, even if (or especially if) the resumption
ClientHello does not include the MFL extension.
- However, it is unclear whether the client is permitted to
attempt to negotiate a new value as part of resumption, or what
happens if the server does not "accept" the new value.
The current OpenSSL implementation (module some nits I'm reviewing fixes
for) *requires* the client to repeat an identical MFL extension during
resumption, if one was successfully negotiated initially.
I personally don't read the quoted terse text from RFC6066 to preclude
renegotiation of the MFL on resumption. It seems more like "good till
revised" rather than "immutable" to me. A server might therefore be
willing to:
- Accept a new value from the client, without aborting the handshake
if it does not match the original choice.
- Decline a new proposed value, and thereby let the original stand.
Is there any sort of "consensus" interpretation of MFL vs. resumption?
- Is stuttering the original choice verbatim a hard requirement?
- Is the client allowed to skip sending MFL on resumption?
- MUST the server abort handshakes on resumption MFL mismatch?
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
