Resumen

  • RFC 9973 incorpora una PSK externa y el secreto (EC)DHE al calendario TLS 1.3 mientras conserva la autenticación por certificado.
  • El binder confirma que ambas partes compartieron el valor seleccionado en este handshake; no confirma quién creó el secreto, cuántos actores lo conservan ni qué acción posterior puede aprobarse.
  • La evidencia operativa debe recorrer creación, provisión, custodia, negociación, autenticación, política de aplicación, commit y resultado observado sin sustituir un tramo por otro.

En el alta inicial de un equipo, una empresa suele buscar dos cosas a la vez: reconocer el dispositivo y proteger la conversación antes de que exista una cuenta normal. Una clave pública puede ayudar a reconocerlo; un secreto inyectado en fábrica puede ofrecer otra condición de confidencialidad. El riesgo aparece cuando la arquitectura llama a ambos elementos “la identidad del dispositivo” y pierde el rastro de quién maneja realmente cada uno.

La RFC 9973, estándar IETF de julio de 2026, define tls_cert_with_extern_psk. En una negociación exitosa, la PSK externa escogida y el secreto compartido (EC)DHE alimentan el calendario de claves de TLS 1.3. La autenticación del servidor —y, si se solicita, la del cliente— sigue dependiendo de las firmas comprobables con las claves públicas de los certificados. Ese reparto es una arquitectura de responsabilidades, no una redundancia ornamental.

El cliente debe llevar junto a la extensión key_share, supported_groups, psk_key_exchange_modes y pre_shared_key. No puede combinarla con early_data. Para la negociación inicial se exige psk_dhe_ke; las PSK ofrecidas deben ser externas, no PSK de reanudación. El servidor responde con la extensión únicamente si acepta una de las PSK externas ofrecidas y también hará autenticación basada en certificado. La asignación de IANA da a la extensión el número 33; no informa qué flota la usa.

La identidad de la PSK no es su historia

El servidor selecciona un índice de la lista que recibió. El cliente y el servidor usan un binder HMAC para comprobar que asocian el mismo secreto a esa identidad en el transcript parcial. Es una prueba de coincidencia para ese protocolo. No prueba que el valor nació de un generador apropiado, que no salió de la fábrica, que no está repetido en una imagen de respaldo, ni que el operador actual recibió derecho a utilizarlo.

La norma insiste en el punto menos cómodo: la generación, distribución y gestión de las PSK externas están fuera de su alcance. Al mismo tiempo, el beneficio de confidencialidad que describe depende de confidencialidad, entropía y autenticidad de la PSK. La RFC 4086 explica por qué una cadena de suministro no puede declarar “aleatorio” y cerrar el expediente. Hay que saber qué clase de proceso creó o derivó la clave, qué dominios recibieron copia y qué procedimiento puede destruirla.

La separación es todavía más importante ante el argumento post-cuántico. RFC 9973 indica que, si un atacante futuro puede quebrar el acuerdo (EC)DH pero no conoce una PSK fuerte, no obtiene por ello los secretos de sesión. No afirma que la firma de certificado se haya vuelto resistente a ese atacante. Añadir una PSK no mejora por sí mismo esa autenticación. RFC 9958 aporta el contexto técnico, no una garantía de despliegue.

Una PSK que se comparte con un grupo tampoco equivale a una identidad grupal autorizada. Los certificados siguen diferenciando la autenticación, pero el círculo de quienes pueden conservar el secreto se ensancha. El uso repetido puede eliminar la separación criptográfica entre sesiones que habría con valores de una sola sesión. Además, la identidad de PSK aparece en claro en el ClientHello y puede servir para vincular conexiones. Rotarla o usar ECH puede reducir ese riesgo, pero no sustituye una decisión sobre el propósito de cada identidad.

Convertir una casilla verde en un expediente verificable

El responsable de claves debe registrar propósito, población de pares, método de generación o derivación, hash y versión permitidos, canal de provisión, custodios, caducidad, rotación y destrucción. El operador de TLS debe poder demostrar la oferta y selección sin copiar el secreto a los logs: extensión aceptada, clase de identidad, psk_dhe_ke, cadena de certificado, resultado Finished o alerta. El dueño de la aplicación debe conservar una tercera pieza: principal reconocido, alcance de la acción, frescura, política aplicable, commit y observación independiente.

Heng Lu llama a preferir el código que realmente corrió. Aquí significa que una política de secretos o una captura de configuración no basta. Hay que observar la transición completa y atribuir cada decisión a su dueño. Su crítica a la diferencia entre control formal y control práctico obliga a preguntar quién puede extraer el valor ahora, no sólo quién aparece como propietario en el inventario.

Fuentes