On Friday, 7 June 2024 08:42:51 CEST, Viktor Dukhovni wrote:
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.
On the other hand the RFC states (section 1.1):
...
A client that requests
session resumption does not in general know whether the server will
accept this request, and therefore it SHOULD send the same extensions
as it would send if it were not attempting resumption.
...
and
...
- If, on the other hand, the older session is resumed, then the
server MUST ignore the extensions and send a server hello
containing none of the extension types. In this case, the
functionality of these extensions negotiated during the original
session initiation is applied to the resumed session.
...
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.
that seems like a bug given the above: if a new session is negotiated
then it should not use the extension, if a session is resumed, then
it must use previously negotiated value
so a client hello that tries to resume a session isn't required to repeat
the same extensions
(I should add it to the tlsfuzzer test coverage:
https://github.com/tlsfuzzer/tlsfuzzer/issues/505 ...)
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:
It is immutable on a per session basis. It can change only with the
change of session (new session or renegotiation)
the only special extension described in RFC 6066 is server_name, as it MAY
be used by the server to figure out if it can resume a session or not, so
it's recommended to repeat it even if the client intends and expects the
session to be resumed
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
