feat request: callback to supply STEKs for session resumption

[jmayclin]

Problem:

The current session resumption APIs (specifically those used to supply STEKs) are not flexible.

For customers that want to enable distributed session resumption, this can be a problem. There is no way to get visibility on which keys are being used or to control the rotation speed.

Solution:

s2n-tls should offer a STEK callback. Customers would be able to implement a STEK provider to have finer control over how STEKs are selected.

struct Key {
    /// included in plaintext in the session ticket
    key_id: Vec<u8>

    /// s2n-tls uses this material to derive the actual encryption key
    key_material: [u8; 32]
}

trait STEKProvider {
    /// provide the key to be used, given the client's SNI
    // todo: maybe this API should also indicate the session ticket lifetime?
    fn get_encryption_key(&self, sni: Option<&[u8]>) -> Option<Key>;

    /// provide the decryption key to be used, given the client's SNI and the KeyId 
    /// from the presented session ticket
    fn get_decryption_key(&self, sni: Option<&[u8]>, id: &[u8]) -> Option<Key>;
}

Requirements / Acceptance Criteria:

The inclusion of the SNI parameter is intended to help address issues like STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets. Customers should use the SNI parameter to derive unique keys per SNI. E.g., the SNI should be used as the info parameter in an HKDF.

Edit: It may be smarter to handle the SNI separation internally as part of our own HKDF logic.

Extension: I also strongly believe that s2n-tls should implement a version of this by default, enabling local resumption for all consumers.

Extension: I also think we could provide a helper library that enables distributed session resumption through KMS, using the generateMAC api.