Resumen

  • KeyUpdate en RFC 9846 avanza el application traffic secret de un solo emisor. El mensaje todavía usa la clave vieja; los records posteriores usan la generación nueva y el receptor actualiza la cadena correspondiente.
  • update_requested exige normalmente una actualización recíproca antes del siguiente dato de aplicación, pero no entrega el scheduler de la conexión. Las direcciones son independientes, las peticiones cruzadas pueden sumar dos generaciones y los límites siguen siendo locales.
  • “Rekey completado” debe dividirse en API programada, transición emitida, transición aceptada y datos nuevos con éxito. Nada de ello certifica que el secreto viejo fue borrado, que la identidad fue revisada o que la aplicación autorizó una acción.

El puente se construye con la clave que se abandona

En una prueba de un canal TLS duradero, el cliente decide refrescar su dirección de envío. Envía KeyUpdate bajo la clave actual y, a partir del record siguiente, cifra con la generación sucesora. El servidor no adivina el cambio al ver ciphertext distinto: autentica primero el mensaje con su estado receptor viejo y solo entonces deriva el nuevo.

Si el valor es update_requested, el servidor envía su propia transición antes de su próximo Application Data. Esa respuesta usa la clave de envío vieja del servidor; luego cambia el sentido inverso. Así, una sola frase operativa —“rotamos la conexión”— esconde dos relojes, dos secuencias y varios puntos de espera.

Cuando los contadores se agregan en un único epoch, una respuesta pendiente parece inconsistencia y dos peticiones cruzadas parecen un salto imposible. La estructura direccional no es detalle criptográfico: determina qué extremo tuvo autoridad sobre cada transición.

La fuente vigente cambió en 2026

RFC 9846 sustituyó a RFC 8446 sin cambiar TLS 1.3 ni romper su compatibilidad. Conserva KeyUpdate como handshake type 24 y solo admite update_not_requested(0) y update_requested(1). Antes de Finished, el mensaje causa unexpected_message; un valor diferente causa illegal_parameter.

KeyUpdate debe terminar alineado en un límite de record previo al cambio. El receptor tiene que verificar la transición protegida por la clave vieja antes de aceptar mensajes con la nueva. Saltarse ese orden puede abrir una truncación. La regla hace que la generación siguiente dependa de una declaración autenticada y no de una heurística sobre fallos de descifrado.

El sucesor se obtiene con HKDF-Expand-Label, el secret direccional actual y la etiqueta traffic upd; después se derivan key e IV. El estándar actual limita el epoch del emisor a 2^48-1. El receptor no aplica ese techo por el otro extremo. Si responder a una petición excedería el límite local, no debe actualizar y debería ignorar el flag, con posible cierre posterior al llegar al límite AEAD.

El derecho del peer cabe en una máquina finita

Una petición con valor 1 tiene efecto normativo. El receptor responde normalmente con valor 0 antes de sus siguientes datos. Sin embargo, no puede obligarlo a procesar trabajo infinito.

Mientras una petición recíproca permanezca pendiente, el iniciador no envía otra. Varias peticiones acumuladas mientras el receptor está silencioso se satisfacen con una sola respuesta. Si ambos inician al mismo tiempo y los mensajes se cruzan, cada uno responde además y ambas direcciones pueden avanzar dos veces.

La concurrencia muestra que no hay un dueño central de epoch. Cada implementación conserva autoridad sobre rate limit, cola de I/O, CPU, rechazo por límites y terminación. La autenticación del mensaje confirma quién pidió; no concede recursos sin cota.

Borrar es una obligación local

RFC 9846 indica que, después de calcular el sucesor, la implementación debería eliminar el traffic secret anterior y sus claves. Un record nuevo exitoso demuestra derivación compatible. No demuestra qué ocurrió en heap, HSM, kTLS, core dump o herramientas de diagnóstico.

La forward secrecy posterior depende de que el borrado ocurra realmente. Por ello, la respuesta KeyUpdate no es una constancia remota de destrucción. La evidencia de memoria pertenece al operador del endpoint y debe basarse en la ruta de código, configuración y pruebas propias.

Tampoco hay nueva identidad. Certificado, service name, autenticación de cliente y permisos de la aplicación siguen siendo los negociados. Renovar el material de records no corrige un proceso comprometido ni convierte una orden sin permiso en una orden válida.

La ejecución no coincide con la llamada

OpenSSL permite SSL_key_update() tras el handshake, pero el cambio progresa durante una operación posterior de lectura, escritura o driving explícito. La aplicación coordina las escrituras pendientes. El retorno de la API solo prueba programación.

GnuTLS ofrece actualización local y, con GNUTLS_KU_PEER, petición al otro extremo. La llamada puede requerir reintento no bloqueante como un envío. Su manual separa rekey de re-authentication.

rustls dispone de refresh_traffic_keys() y suele vigilar los límites de confidencialidad. Si la aplicación externaliza la protección mediante su kernel API, debe contar records, renovar y abortar por sí misma. Una política portable necesita eventos y resultados, no asumir que todas las bibliotecas ponen bytes en la red al devolver la función.

QUIC y DTLS cambian la gramática

QUIC usa TLS 1.3 para el handshake, pero prohíbe TLS KeyUpdate. Su Key Phase, ACK de paquetes y derivación quic ku reemplazan el mecanismo. Medir solo handshake type 24 produciría un falso cero en QUIC.

DTLS 1.3 sí usa KeyUpdate, pero añade epochs, ACK, retención de claves viejas y reglas para datagramas perdidos o reordenados. Una respuesta puede cruzarse con la petición y no la acusa implícitamente. Cerca del límite, puede ignorar una petición recíproca que lo exceda.

El campo transport no es decorativo. Sin él, una plataforma junta tres eventos distintos bajo rekey y pierde qué prueba exige cada uno.

Evidencia sin copiar secrets

Registrar conexión, rol, protocolo, dirección, generaciones, iniciador, request flag, autenticación del mensaje viejo, boundary, writes pendientes, primer record nuevo, cruces, coalescing, rate limit y alerta final. Mantener separados scheduled, emitted, accepted y data-succeeded.

TLS 1.3 cifra KeyUpdate; una captura por sí sola no suele identificarlo. En laboratorio se pueden combinar callbacks, contadores y key log limitado. En producción, exportar secrets de forma continua para mejorar una gráfica aumentaría la superficie de compromiso.

El borrado del material viejo usa otra evidencia local. Se correlaciona con el evento, pero no se deduce de él.

Fuentes