Resumen

  • La versión 01 de un Internet-Draft individual propone elegir SHAKE256 o TurboSHAKE256 para el calendario de claves TLS sin cambiar la suite criptográfica. La versión 00 dejaba fuera DTLS y los autenticadores exportados; la nueva les dedica reglas.
  • Una aplicación que construya un autenticador exportado fuera de la biblioteca TLS necesita el identificador del KDF negociado, o saber que se usó el calendario habitual, y distinguir TLS de DTLS. Los datos que entrega TLS-Exporter por sí solos no comunican esas decisiones.

Una empresa actualiza la biblioteca que hace el saludo TLS y deja intacto el servicio que comprueba identidades después. La conexión abre; la prueba posterior falla. Ese resultado sería posible si el segundo programa siguiera calculando con el hash anunciado por la suite cuando la biblioteca ya hubiera negociado otro calendario. La nueva revisión del borrador XOF describe exactamente esa costura técnica, sin documentar un fallo de producto concreto.

La propuesta no crea nuevas suites. Añade la extensión schedule_profile, que negocia el KDF aparte del cifrado. Si nadie la usa, rige el calendario de TLS 1.3: HKDF con el hash de la suite. Si los extremos acuerdan uno de los dos perfiles XOF, ese KDF gobierna las derivaciones y el hash del diálogo; el hash todavía impreso en el nombre de la suite deja de gobernar el calendario. Leer solo TLS_AES_128_GCM_SHA256 ya no basta para afirmar cómo se generaron las claves.

La versión 00 de julio apartaba expresamente DTLS 1.3 y los Exported Authenticators. El texto del 27 de octubre amplía el alcance y propone actualizar cuatro RFC. Entre ellos está RFC 9261, que permite a cualquiera de los dos extremos autenticarse después del saludo. Bajo sus reglas actuales, el hash del autenticador procede de la suite. Con el KDF XOF propuesto, la sección 14.2 lo sustituye por el TranscriptHash de 64 octetos del KDF y cambia también las salidas exportadas y el MAC de Finished. Una conexión sin la nueva extensión conserva el cálculo vigente.

La obligación más reveladora aparece al final de esa sección. Si el autenticador vive fuera de la biblioteca TLS, debe recibir el identificador del KDF negociado o la indicación explícita de que no se negoció uno nuevo. También necesita saber si se trata de TLS o DTLS, porque DTLS usa otra etiqueta interna. Una interfaz que solo ofrece TLS-Exporter(label, context, length) entrega material, pero oculta la elección que determina cómo verificarlo. Actualizar una biblioteca y olvidar la aplicación puede dejar autenticadores incompatibles.

El KDF viaja también con las claves precompartidas y los tickets de reanudación. RFC 9258 ya ofrece los identificadores que emplea esta propuesta. La firma del certificado sigue otra negociación: una conexión con calendario XOF aún puede utilizar SHA-2 en la autenticación. Datatracker mantiene el texto como borrador individual en I-D Exists. Falta una prueba pública de interoperabilidad del autenticador externo con el nuevo KDF; una verificación de Finished en TLS y DTLS zanjaría esa cuestión.