[TLS 1.3] Extend CredentialsManager for upcoming TLS 1.3 PSK #3622
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This attempts to step away from the generic
Credentials_Manager::psk()
method that is parameterized withtype
andcontext
. Instead, the class now has dedicated getter-methods for the specific keys it manages.Credentials_Manager::session_ticket_key()
Credentials_Manager::dtls_cookie_secret()
Credentials_Manager::find_preshared_keys()
The TLS 1.2 implementation keeps using the
::psk()
method as before -- so existing applications that override it will continue to work as before. We think, dedicated methods for specific artefacts is much more on-par with the other TLS dependency classes (e.g.Callbacks
andPolicy
). Additionally, its easier to understand the API like that.New applications can make use of the added default implementation of
::psk()
that orchestrates the new dedicated methods as shown in the table above. With Botan 4.0 the::psk()
method should probably disappear entirely. (AndCredentials_Manager
should perhaps move into theTLS
namespace.)The new methods
find_preshared_keys()
andchoose_preshared_key()
take into account that one can offer multiple PSKs in a TLS 1.3 Client Hello. The server then gets to choose which PSK it wants to negotiate with.Given that TLS 1.2 pre-negotiates a singular PSK identity prior to actually requesting the actual PSK-value, it can benefit from the same
find_preshared_keys()
(through the legacypsk()
). If exactly one PSK identity is requested, it should be guaranteed that at most one PSK is returned byfind_preshared_keys()
.The actual TLS 1.3 PSK implementation will come in a follow-up.