Summary

  • El BoF CURRENT estudió usar MLS para las claves del record layer de TLS 1.3, pero sigue sin charter y las actas de IETF 126 dicen que el problema aún no se entendía con suficiente claridad.
  • En el perfil bipartito, quien aplica el commit envía un EpochKeyUpdate autenticado; el iniciador no puede activar su estado pendiente hasta recibir y validar esa confirmación.
  • Actualización enviada, clave instalada, secreto antiguo eliminado y tráfico de aplicación aceptado bajo la nueva época son recibos distintos.

Entre dos épocas

A envía ConnectionUpdate. B valida y aplica el commit, devuelve EpochKeyUpdate y puede empezar a usar el material nuevo. B tiene razón al registrar un cambio. A permanece en Awaiting EpochKeyUpdate; no puede convertir su estado provisional en vigente hasta autenticar la respuesta con el estado derivado de su commit pendiente.

La asimetría evita que la intención local se convierta en prueba de recepción remota. El riesgo aparece cuando una consola comprime ese recorrido en “rotación completada”. Un hecho local verdadero se transforma entonces en una afirmación sobre el par que nunca observó.

Los dos textos son Internet-Drafts individuales en revisión 01. CURRENT continúa siendo un BoF no chartered. En Viena se cuestionaron el alcance del problema, la limitación a dos partes frente a casos de uso multipartitos y la posible suficiencia de extensiones TLS existentes. No hay un estándar aprobado que pueda anunciarse como resultado.

PCS depende de procesar y borrar

RFC 9420 dice que una propuesta Update no produce por sí sola post-compromise security. Debe incorporarse en un Commit procesado por los miembros. La garantía nace cuando se procesa el Commit, no cuando se crea. La forward secrecy requiere además borrar claves privadas antiguas y claves de mensaje usadas.

Los borradores MLS-TLS exportan secretos desde MLS para proteger registros TLS y hacen circular commits dentro del canal. La confirmación de época demuestra conocimiento del nuevo estado. No prueba por sí sola que toda copia vieja desapareció, que el atacante perdió acceso, que la identidad del par sigue siendo válida ni que la aplicación conservó servicio.

Una etiqueta “PCS” describe una propiedad del diseño. La operación necesita fechar cuándo cada condición se hizo real.

Colisiones y reanudaciones dejan procedencia

Si ambos extremos actualizan a la vez, el perfil resuelve el cruce mediante los roles iniciales: uno ignora el commit rival; el otro abandona el suyo y procesa el del par. Al reanudar una conexión puede retransmitirse un commit pendiente. El receptor debe reconocer uno ya aplicado y no repetirlo. Detectar la interrupción queda fuera del perfil.

Guardar solo el número final de época elimina estas diferencias. Después no se puede saber si la convergencia llegó por confirmación ordinaria, resolución de colisión, retransmisión o nueva reanudación. Tampoco se puede medir cuánto tiempo permaneció útil el material anterior.

Ocho recibos

La Minimum Initial Specification de Lu Heng limita la capa común a transiciones deterministas. Running-Code Primacy sitúa por encima el estado que cada extremo realmente validó e instaló. La disciplina de capas de realidad separa: creación, envío, autenticación remota, aplicación remota, confirmación, instalación local, borrado y primer registro de aplicación autenticado bajo la nueva época.

El propio borrador exige cautela: su análisis de seguridad y partes de la separación entre protocolos siguen marcados como TODO. Un BoF puede abrir trabajo valioso; no certifica que el trabajo esté terminado.

Fuentes y límites

Estas fuentes no prueban grupo chartered, consenso IETF, borrador adoptado, RFC, análisis de seguridad completo, interoperabilidad, despliegue, recuperación medida, PQC en producción, incidente ni resultado de servicio.