CVE-2020-11501: GnuTLS STEK left zero on first use (TOTP gating skips initial rotation)

GnuTLS 3.6.4 through 3.6.12 ships a session-ticket encryption key (STEK) that is effectively all-zero for the first TOTP rotation window after a server starts. _gnutls_initialize_session_ticket_key_rotation() (lib/stek.c) stores the user's master key into session->key.initial_stek and sets totp.last_result = totp_next(), but never derives session->key.session_ticket_key. The first call to _gnutls_get_session_ticket_encryption_key() then invokes rotate(), where totp_next() returns 0 because result == last_result, so the if (t > 0) memcpy(session->key.session_ticket_key, key, sizeof(key)); branch is skipped. session_ticket_key stays at its calloc-zero value. The 64-byte STEK splits into key_name(16)/enc_key(32)/mac_key(16) — all zero. Impact: TLS 1.2 confidentiality loss (any ticket can be decrypted with a zero AES-128-CBC key) and TLS 1.3 authentication bypass (attacker forges a resumption ticket under the zero MAC key). Briefing labels this "DTLS SRTP timing side-channel" but the real bug is in stek.c, not lib/ext/srtp.c — note that for future agents.