Resumen

  • RFC 9852 / BCP 195, coescrito por Rich Salz y Nimrod Aviram, dice que un protocolo nuevo que use TLS debe asumir disponible TLS 1.3 y especificarlo como predeterminado. La obligación recae sobre la especificación que se redacta.
  • Esa obligación no es un recibo de un endpoint en producción. La versión negociada, configuración, autenticación del par, aceptación de la aplicación y recuperación son hechos separados. El RFC excluye expresamente DTLS de esta prescripción.

En estándares, la palabra debe es útil porque evita que una elección ya resuelta parezca opcional. Pero una exigencia normativa no es una medición. Convertirla en la frase «el servicio ya está desplegado con TLS 1.3» pide al documento que informe de algo que no vio.

RFC 9852, New Protocols Using TLS Must Require TLS 1.3, es una Best Current Practice de IETF, BCP 195. Identifica a Rich Salz y Nimrod Aviram como autores; el resultado es consenso de IETF, no una declaración individual de operación. Su pregunta es concreta: ¿qué debe escribir una especificación nueva que usa TLS? Debe asumir TLS 1.3 disponible y fijar TLS 1.3 como valor predeterminado.

Eso no decide lo que ocurre al otro lado de una conexión determinada. Un protocolo puede contener la regla mientras un operador todavía necesita observar qué versión negociaron realmente un cliente y un endpoint, qué política local fue aplicada, qué autenticación del par resultó pertinente, qué aceptó la aplicación y cómo se detectó o recuperó un fallo. Son uniones con dueños diferentes, no omisiones de la BCP.

El límite de DTLS deja el alcance aún más claro. RFC 9852 dice que la prescripción se refiere a TLS solamente. Como DTLS 1.3 no está ampliamente disponible ni desplegado, no se aplica a DTLS en ninguna versión. El rótulo «TLS 1.3 obligatorio» borra una excepción que el texto coloca deliberadamente en primer plano.

El RFC explica que TLS 1.3 se usa ampliamente, cuenta con pruebas de seguridad exhaustivas y mejora deficiencias de seguridad y privacidad de TLS 1.2. También reconoce que TLS 1.2 puede configurarse con buenas propiedades, aunque normalmente exige configuración a medida. La migración poscuántica forma parte de la razón para cambiar la base, pero el documento deja fuera de alcance decidir cuándo una aplicación concreta necesita PQC. Es razón para redactar una regla, no telemetría de un servicio.

La Primacía del Código en Ejecución pide conservar las piezas. La BCP prueba la regla de diseño; una configuración prueba la intención local; una observación de negociación prueba un hecho de conexión; los registros de autenticación, aplicación y recuperación prueban otras cosas. Mezclarlos en un único estado de «cumplimiento» vuelve imposible saber qué se verificó realmente.

Por ello, el autor debe aplicar BCP 195 al definir el protocolo y el operador debe declarar despliegue sólo con las observaciones que le corresponden. Guardar política, negociación, autenticación requerida, efecto de aplicación y recuperación permite que la norma y el sistema se respalden sin suplantarse.

Sources