No estoy completamente seguro de entender el concepto. Pero creo que el punto es que con las claves asimétricas a corto plazo ("efímeras") (DH, ECDH hoy en día. Pero "RSA efímero" solía ser una cosa también.) Hay varias opiniones sobre exactamente cómo a corto plazo se supone que estas claves son.
En la paranoia alta, el término "corto plazo" puede significar "una vez para cada conexión". Y en la parte baja de la paranoia, "corto plazo" puede significar "hasta que reinstale el software porque las claves compartidas solo se generan en la instalación" . - Y todo en el medio. Por ejemplo, con F5, creo que el valor predeterminado es regenerar las claves DH una vez por hora. Pero opcionalmente puede configurar el "parámetro de uso de DH único" para que se regenere realmente para cada conexión. Y OpenSSL tiene una opción llamada "SSL_OP_SINGLE_DH_USE" que, creo, hace lo mismo. Y de lo contrario, las claves DH solo se regeneran al reiniciar el servidor. Y con Citrix NetScaler puede definir un número máximo de conexiones después de las cuales se regenerarán las claves DH.
(Consulte una respuesta mía relacionada .)
No creo que las especificaciones de TLS especifiquen con qué frecuencia se deben regenerar las claves efímeras. Creo que dejan esto completamente en manos del implementador y nunca hacen un comentario explícito o implícito.
Ahora, ¿qué significa esto de seguridad? Supongamos que tiene una conexión TLS. Con el mejor de los casos, uso único de DH, en un extremo. Y un caso no tan bueno, la regeneración de claves DH al reiniciar el servidor, en el otro extremo. Y supongamos que tenemos un hombre en el atacante medio que está empleando un ataque "para llevarlo todo". Y solo registra el tráfico cifrado durante unas semanas.
Ahora, si ese atacante de alguna manera obtiene un compromiso no completo de uno de los extremos de la conexión, como por ejemplo, una instantánea con RAM de uno de esos extremos, ¿qué le da eso?
Si tiene la suerte de obtener una instantánea del final no tan bueno, esto le permitiría a ese atacante descifrar de forma retroactiva cualquier conexión anterior con DHE asegurada del pasado. Desde el reinicio del servidor. Y también EN EL FUTURO hasta el próximo reinicio.
Y no importa si todos los otros extremos cambian constantemente su parte la danza clave efímera.
Espero que esto responda de alguna manera a tu pregunta.
Nota al margen: en realidad, hubo DEMANDA para los clientes / servidores TLS que NO tienen mucha efemeralidad (¿es eso una palabra?) en sus claves efímeras durante el proceso de diseño de TLS 1.3: enlace