Resumen

  • La RFC 3268 no sustituyó la negociación de TLS: añadió doce identificadores de suites AES al menú previo, con seis familias de intercambio/autenticación y dos tamaños de clave.
  • AES-256 no autentica por sí solo a un servidor ni aporta secreto hacia adelante. Esas propiedades dependen del método de negociación y de cómo se implemente.

AES necesitaba una casilla que ambos extremos entendieran

Que AES se convirtiera en un estándar no lo volvía automáticamente negociable en TLS. Cliente y servidor debían acordar una forma común de nombrar el conjunto de parámetros. TLS 1.0 ya ofrecía esa interfaz: el cliente enviaba una lista de suites en ClientHello y el servidor elegía una compatible. En la RFC 2246, la suite reunía el intercambio de claves, el cifrado de los datos y el algoritmo de autenticación de mensajes.

La RFC 3268, publicada en junio de 2002, reutilizó esa estructura. Añadió AES en modo CBC con HMAC-SHA-1, pero no una única opción «AES». Definió seis variantes de negociación: RSA; DH estático con certificados DSS o RSA; DHE efímero firmado con DSS o RSA; y DH anónimo. Cada variante se ofrecía con claves AES de 128 o 256 bits: seis por dos, doce identificadores.

La lista conservaba diferencias que el nombre del cifrado no podía borrar. RSA, DH autenticado y DH anónimo no son intercambiables. DHE puede aportar secreto hacia adelante si las claves efímeras son nuevas, se destruyen correctamente y proceden de un generador aleatorio sólido. DH anónimo no autentica al interlocutor y permite ataques de intermediario si no existe otro método que vincule a ambas partes con el mismo mensaje Finished. Elegir AES-256 no contesta nada de eso.

AES admite claves de 128, 192 y 256 bits. La RFC eligió 128 y 256 para no multiplicar todavía más los nombres de suite. Las doce variantes utilizaban bloques AES de 128 bits; una clave mayor no implicaba un bloque mayor. CBC y SHA-1 dentro de HMAC también formaban parte del paquete. «AES» nombraba solo una pieza.

Compatibilidad a cambio de más identificadores

La introducción de la RFC observó que las suites DHE disponibles entonces se apoyaban en triple-DES, además de algunas variantes de exportación con claves insuficientes. AES podía añadirse sin alterar ClientHello ni el método de selección de TLS 1.0. Pero cada combinación nueva debía tener un nombre, un código, una política y una implementación coherentes.

Que IANA registre una suite no demuestra que un producto la admita, la prefiera o la negocie. La evolución posterior aclara la arquitectura: TLS 1.2 todavía agrupaba varios componentes en muchas suites; TLS 1.3 limitó el nombre de la suite al algoritmo AEAD y al hash, mientras separó los grupos de intercambio y las firmas. La RFC 3268 es parte de la historia de dónde residían las decisiones de TLS, no solo de cuándo apareció AES.

Esa es su lección duradera. El algoritmo, la longitud de clave, la autenticación, el intercambio y el formato de registro representan dimensiones distintas. Una suite es un paquete negociado; leer una sola palabra como veredicto sobre toda la conexión confunde la etiqueta con la arquitectura.

Fuentes