To implement this, we should add a new global parameter, QUIC_PARAM_GLOBAL_RETRY_CONFIG, that takes as input the following info:

• An CXPLAT_AEAD_TYPE defining the type of key to create
• The raw bytes (length depend on AEAD type, see CxPlatKeyCreate)
• The key rotation interval

The secret will need to be stored in MsQuicLib.BaseRetrySecret. The partition logic will need to be updated to account for a configurable AEAD type (instead of hard coded CXPLAT_AEAD_AES_256_GCM) and key rotation interval (instead of the hard coded 30 sec).

We will also need to standardize and document the method for calculating derived keys based on time and base secret. The current logic is:

    uint8_t RawKey[CXPLAT_AEAD_AES_256_GCM_SIZE];
    CxPlatCopyMemory(
        RawKey,
        MsQuicLib.BaseRetrySecret,
        sizeof(MsQuicLib.BaseRetrySecret));
    for (size_t i = 0; i < sizeof(KeyIndex); ++i) {
        RawKey[i] ^= ((uint8_t*)&KeyIndex)[i];
    }

Another thought: if we use a parameter for this, it would be required to be wired up to all the layers on top. For instance, if you want Windows HTTP to take advantage of this, HTTP and possibly IIS would have to be updated.

OR, we have a registry key that backs this as well, though, it's generally not a great idea to store secrets in the registry.

If the app/admin is setting the key directly, then MsQuic wouldn't be generating subkeys from that anymore, right?
So instead of keeping the subkeys, MsQuic would need to store the previous key in memory, once the app/admin sets a new one, and until the app/admin sets the next one, or the time period expires.