TLS Supported Groups: Kurven, FFDHE und ML-KEM

secp256r1

ECDHE auf P-256: der Schlüsselaustausch, den RFC 8446 für jede Implementierung von TLS 1.3 vorschreibt.

secp256r1 (23) ist die Gruppe, die jede Implementierung von TLS 1.3 unterstützen muss (MUST, RFC 8446 §9.1); damit ist sie der Fallback, der immer funktioniert. Der Key Share ist ein unkomprimierter Punkt von 65 Byte; TLS 1.3 verbietet komprimierte Punkte für diese Kurven. Siehe P-256.

secp384r1

ECDHE auf P-384, vorgeschrieben durch die Suite CNSA 1.0 der NSA.

secp384r1 (24) ist bei der IANA als empfohlen gekennzeichnet und die Gruppe CNSA-konformer Konfigurationen. Der Key Share ist 97 Byte groß. Das Hybridverfahren SecP384r1MLKEM1024 kombiniert die Gruppe mit ML-KEM-1024 für die Umstellung auf CNSA 2.0. Siehe P-384.

x25519

Diffie-Hellman auf der elliptischen Kurve Curve25519, der klassische Standard-Schlüsselaustausch von TLS 1.3.

x25519 (29) ist der häufigste Key Share in TLS 1.3 und die klassische Hälfte von X25519MLKEM768. Laut RFC 8446 §9.1 sollten (SHOULD) Implementierungen die Gruppe neben dem verpflichtenden secp256r1 unterstützen. Key Shares sind 32 Byte groß. Siehe Curve25519.

ffdhe2048

Die 2048-Bit-Gruppe für Diffie-Hellman über endlichen Körpern aus RFC 7919.

RFC 7919 ersetzte vom Server gewählte DHE-Parameter – oft 1024 Bit lang, manchmal von vielen Servern geteilt und vorberechenbar, wie der Logjam-Angriff zeigte – durch fünf feste, benannte Gruppen. TLS 1.3 handelt sie über supported_groups aus. RFC 10015 §3 verbietet FFDHE-Cipher-Suites in TLS 1.2; diese Gruppen spielen daher nur noch für TLS 1.3 eine Rolle, wo sie selten genutzt werden.

MLKEM768

ML-KEM-768 allein, ohne klassische Komponente: ein reiner Post-Quanten-Schlüsselaustausch für TLS.

MLKEM768 (513) verwendet ausschließlich das KEM aus FIPS 203. Wäre ML-KEM gebrochen, würde nichts mehr die Sitzung schützen; deshalb setzt das Web auf Hybride wie X25519MLKEM768. Die reinen Gruppen richten sich an Umgebungen, deren Richtlinien ausschließlich Post-Quanten-Algorithmen verlangen.

SecP256r1MLKEM768

Das Hybridverfahren aus ECDHE auf P-256 und ML-KEM-768 für Umgebungen, die bei vom NIST zugelassenen Kurven bleiben müssen.

SecP256r1MLKEM768 (0x11EB, RFC 10024) kombiniert einen Key Share auf P-256 mit ML-KEM-768. Da beide Komponenten vom NIST zugelassen sind, eignet sich das Verfahren für FIPS-validierte Umgebungen, die X25519 nicht verwenden können.

X25519MLKEM768

Der hybride Post-Quanten-Schlüsselaustausch, den Browser und große Server standardmäßig aushandeln: X25519 kombiniert mit ML-KEM-768.

X25519MLKEM768 (0x11EC, RFC 10024) sendet einen ML-KEM-768-Kapselungsschlüssel und einen X25519-Key-Share in einem einzigen Eintrag von key_share und verkettet die beiden gemeinsamen Geheimnisse; so bleibt die Sitzung geheim, solange einer der beiden Algorithmen hält. Das Verfahren schützt heutigen Datenverkehr vor Angriffen nach dem Muster „harvest now, decrypt later“ durch künftige Quantencomputer. Die IANA kennzeichnet es als empfohlen.

Der Key Share im ClientHello ist etwa 1,2 KB groß; das ClientHello überschreitet damit ein TCP-Segment, wodurch Middleboxes aufgefallen sind, die aufgeteilte ClientHellos nicht verarbeiten können. Frühere Implementierungen nutzten den vorläufigen Codepoint X25519Kyber768Draft00 (0x6399) aus der Entwurfsphase; er ist inzwischen veraltet.