From RFC 8446 section 4.6.3:
If the request_update field is set to "update_requested", then the
receiver MUST send a KeyUpdate of its own with request_update set to
"update_not_requested" prior to sending its next Application Data
record.
Say I have a client connection that sends things to the server, but doesn't read anything that's sent to it after the handshake (it doesn't drain any incoming traffic, doesn't call SSL_read()
, etc). If the key update is sent by the server and not "required" then it's all fine - the server can keep sending things and it has no effect on what we send to it. However, what is the scenario when it sends a key update that asks the client to update its own keys as well? As the client is not draining any data, it can't ever know that the server sent that message. RFC 8446 also says the folowing:
Note that implementations may receive an arbitrary number of
messages between sending a KeyUpdate with request_update set to
"update_requested" and receiving the peer's KeyUpdate, because those
messages may already be in flight.
Are there ANY implementations of TLS 1.3 (like OpenSSL or GNU TLS) that actually enforce a required key update? As in, do they take any action if the peer fails to comply? This enforcing process may be something trivial like sending an alert after some given time and thus dropping the connection, or only letting a few new messages come in and after some threshold drop the connection (instead of after a timeout). It would be ideal for me as the client to keep sending things unbothered of any other protocol messages that may be appearing at my end.