Grupos admitidos en TLS: curvas, FFDHE y ML-KEM

secp256r1

ECDHE sobre P-256: el intercambio de claves que el RFC 8446 hace obligatorio para toda implementación de TLS 1.3.

secp256r1 (23) es el grupo que una implementación de TLS 1.3 debe (MUST) admitir (RFC 8446 §9.1), lo que lo convierte en la alternativa que siempre funciona. Su key share es un punto sin comprimir de 65 bytes; TLS 1.3 prohíbe los puntos comprimidos para estas curvas. Consulta la curva P-256.

secp384r1

ECDHE sobre P-384, exigido por la suite CNSA 1.0 de la NSA.

La IANA marca secp384r1 (24) como recomendado, y es el grupo de las configuraciones que cumplen CNSA. Su key share ocupa 97 bytes. El híbrido SecP384r1MLKEM1024 lo combina con ML-KEM-1024 para la transición a CNSA 2.0. Consulta la curva P-384.

x25519

Diffie–Hellman de curva elíptica sobre Curve25519, el intercambio de claves clásico predeterminado de TLS 1.3.

x25519 (29) es el key share más común de TLS 1.3 y la mitad clásica de X25519MLKEM768. El RFC 8446 §9.1 recomienda (SHOULD) que las implementaciones lo admitan, junto al obligatorio secp256r1. Los key shares ocupan 32 bytes. Consulta Curve25519.

ffdhe2048

El grupo Diffie–Hellman de campo finito de 2048 bits del RFC 7919.

El RFC 7919 sustituyó los parámetros DHE elegidos por el servidor —a menudo de 1024 bits, a veces compartidos por muchos servidores y precalculables, como demostró el ataque Logjam— por cinco grupos fijos con nombre. TLS 1.3 los negocia mediante supported_groups. El RFC 10015 §3 prohíbe los conjuntos de cifrado FFDHE en TLS 1.2, así que estos grupos ya solo importan en TLS 1.3, donde se usan poco.

MLKEM768

ML-KEM-768 solo, sin componente clásico: un intercambio de claves TLS puramente poscuántico.

MLKEM768 (513) usa solo el KEM de FIPS 203. Si ML-KEM se rompiera, nada protegería la sesión, y por eso la web usa híbridos como X25519MLKEM768; los grupos puros están pensados para entornos cuya política exige algoritmos exclusivamente poscuánticos.

SecP256r1MLKEM768

El híbrido de ECDHE sobre P-256 con ML-KEM-768, para despliegues que deben seguir usando curvas aprobadas por el NIST.

SecP256r1MLKEM768 (0x11EB, RFC 10024) combina un key share P-256 con ML-KEM-768. Como ambos componentes están aprobados por el NIST, encaja en despliegues validados según FIPS que no pueden usar X25519.

X25519MLKEM768

El intercambio de claves híbrido poscuántico que los navegadores y los grandes servidores negocian de forma predeterminada: X25519 combinado con ML-KEM-768.

X25519MLKEM768 (0x11EC, RFC 10024) envía una clave de encapsulación ML-KEM-768 y un key share X25519 en una sola entrada key_share y concatena los dos secretos compartidos, de modo que la sesión sigue siendo secreta mientras resista cualquiera de los dos algoritmos. Protege el tráfico actual frente a los ataques de tipo «cosechar ahora, descifrar después» de las futuras computadoras cuánticas. La IANA lo marca como recomendado.

El key share del ClientHello ocupa unos 1,2 KB, lo que hace que el ClientHello supere un segmento TCP y ha dejado al descubierto equipos intermedios (middleboxes) que no saben manejar un ClientHello dividido. Los primeros despliegues usaban el punto de código previo al estándar X25519Kyber768Draft00 (0x6399), hoy obsoleto.