Proposal: Add TLS1.3 KeyUpdate request to SslStream

[ritchiecarroll]

Although version 1.3 of TLS forbids renegotiation to prevent specific attack vectors, it now supports a new key and initialization vector update request, i.e., the KeyUpdate handshake message: https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.3

For use cases with long running TLS connections, as measured by either by connection time or by data transfer volume, it is a good idea to request new keys for security reasons.

Algorithms and guidance have been defined to determine when keys should be updated based on data throughput ^[1] [2], but definitive recommendations on when keys should be updated based solely on time is a little harder to come by, e.g., 24 hours or 8 hours.

Regardless, the fact remains that currently it is not possible to manually request a key update through .NET.

Some implementations of SSL already support a configurable automatic key update as a function of throughput in bytes, e.g., ErLang key_update_at defaulting to ~353 TB and JSSE jdk.tls.keyLimits. Implementing a .NET runtime configuration option for a specific TLS connection that would automatically invoke a key update based on data throughput, with a reasonable default, would immediately put .NET TLS v1.3 implementations in a more secure position. That said, allowing the user to call the function manually is still desirable, IMO, to accommodate use cases based on other criteria.

---

Implementation Thoughts

Location of Function within .NET runtime

Since System.Net.Security.SslStream is used for enabling TLS in either client or sever scenarios and the client or the server can request key updates (different paths, different keys), this seems like a logical target location for implementing the feature.

For example: public Task RequestKeyUpdate(KeyUpdateOptions options). TLS versions less than 1.3 could throw NotImplemented exception.

Native Implementation of Key Update Functionality

Since .NET wraps other OS or platform specific APIs for its TLS implementation, this functionality will be exposed via the native library.

• For Linux this is OpenSSL and the function call is as follows: https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html

• For Windows, the implementation involves the use of the Schannel SSP. The Schannel implementation is opaque and fairly complex, so I cannot currently determine which function call(s) would be necessary in order to invoke the TLS 1.3 KeyUpdate.

• For OSX, the implementation looks to be the Secure Transport or Network. I found a callback for receiving key updates, a quick search did not reveal a request function - but it may exist.

---

The following paper presents an algorithm on when to update keys as a function of unencrypted bytes:

^[1] Limits on Authenticated Encryption Use in TLS, Atul Luykx and Kenneth G. Paterson

The following draft RFC provides guidance on limiting the use of keys to bound the advantage given to an attacker:

^[2] Usage Limits on AEAD Algorithms, F. Günther, M. Thomson, and C. A. Wood

[danmoseley]

@wfurt