4. Empfehlungen: Cipher-Suites

TLS 1.2 bot eine erhebliche Flexibilität bei der Auswahl von Cipher-Suites. Leider hat sich die Sicherheit einiger dieser Cipher-Suites im Laufe der Zeit so weit verschlechtert, dass einige als unsicher bekannt sind (dies ist einer der Gründe, warum TLS 1.3 diese Flexibilität eingeschränkt hat). Eine falsche Serverkonfiguration führt zu keiner oder reduzierter Sicherheit. Dieser Abschnitt enthält Empfehlungen zur Auswahl und Aushandlung von Cipher-Suites.

4.1. Allgemeine Richtlinien

Kryptographische Algorithmen werden im Laufe der Zeit schwächer, da sich die Kryptoanalyse verbessert: Algorithmen, die früher als stark galten, werden schwach. Daher müssen Cipher-Suites, die schwache Algorithmen verwenden, auslaufen und durch sicherere Cipher-Suites ersetzt werden. Dies hilft sicherzustellen, dass die gewünschten Sicherheitseigenschaften weiterhin gelten. SSL/TLS gibt es seit über 20 Jahren, und viele der Cipher-Suites, die in verschiedenen Versionen von SSL/TLS empfohlen wurden, gelten heute als schwach oder zumindest nicht so stark wie gewünscht. Daher modernisiert dieser Abschnitt die Empfehlungen zur Auswahl von Cipher-Suites.

• Implementierungen DÜRFEN KEINE Cipher-Suites mit NULL-Verschlüsselung aushandeln.

  Grund: NULL-Cipher-Suites verschlüsseln den Datenverkehr nicht und bieten daher keinen Vertraulichkeitsdienst. Jede Entität im Netzwerk mit Zugriff auf die Verbindung kann den Klartext des Inhalts sehen, der zwischen Client und Server ausgetauscht wird. Dennoch rät dieses Dokument Software nicht davon ab, NULL-Cipher-Suites zu implementieren, da sie für Tests und Fehlerbehebung nützlich sein können.

• Implementierungen DÜRFEN KEINE RC4-Cipher-Suites aushandeln.

  Grund: Die RC4-Stromchiffre weist verschiedene kryptographische Schwächen auf, wie in [RFC7465] dokumentiert. Beachten Sie, dass DTLS die Verwendung von RC4 bereits ausdrücklich verbietet.

• Implementierungen DÜRFEN KEINE Cipher-Suites aushandeln, die weniger als 112 Bit Sicherheit bieten, einschließlich der sogenannten "Export-Grade"-Verschlüsselung (die 40 oder 56 Bit Sicherheit bietet).

  Grund: Basierend auf [RFC3766] sind mindestens 112 Bit Sicherheit erforderlich. 40-Bit- und 56-Bit-Sicherheit (die in sogenannten "Export-Chiffren" zu finden sind) gelten heute als unsicher.

• Implementierungen SOLLTEN KEINE Cipher-Suites aushandeln, die Algorithmen verwenden, die weniger als 128 Bit Sicherheit bieten.

  Grund: Cipher-Suites, die 112 Bit oder mehr, aber weniger als 128 Bit Sicherheit bieten, gelten derzeit nicht als schwach; es wird jedoch erwartet, dass ihre Nutzungsdauer kurz genug ist, um die Unterstützung stärkerer Cipher-Suites an dieser Stelle zu rechtfertigen. Es wird erwartet, dass 128-Bit-Chiffren mindestens mehrere Jahre und 256-Bit-Chiffren bis zum nächsten grundlegenden technologischen Durchbruch sicher bleiben. Beachten Sie, dass aufgrund sogenannter "Meet-in-the-Middle"-Angriffe [Multiple-Encryption] einige ältere Cipher-Suites (z. B. 168-Bit Triple DES (3DES)) eine effektive Schlüssellänge haben, die kleiner ist als ihre nominelle Schlüssellänge (112 Bit im Fall von 3DES). Solche Cipher-Suites sollten anhand ihrer effektiven Schlüssellänge bewertet werden.

• Implementierungen SOLLTEN KEINE Cipher-Suites aushandeln, die auf RSA-Schlüsseltransport basieren, auch bekannt als "statisches RSA".

  Grund: Diese Cipher-Suites, deren zugewiesene Werte mit der Zeichenfolge "TLS_RSA_WITH_*" beginnen, haben mehrere Nachteile, vor allem, dass sie keine Forward Secrecy unterstützen.

• Implementierungen SOLLTEN KEINE Cipher-Suites aushandeln, die auf einer nicht-ephemeren (statischen) Finite-Field Diffie-Hellman (DH)-Schlüsselvereinbarung basieren. Ebenso SOLLTEN Implementierungen KEINE nicht-ephemere Elliptic Curve DH-Schlüsselvereinbarung aushandeln.

  Grund: Die ersteren Cipher-Suites, die zugewiesene Werte mit dem Präfix "TLS_DH_" haben, haben mehrere Nachteile, vor allem, dass sie keine Forward Secrecy unterstützen. Den letzteren ("TLS_ECDH_") fehlt ebenfalls Forward Secrecy und sie unterliegen Angriffen mit ungültigen Kurven [Jager2015].

• Implementierungen MÜSSEN Cipher-Suites unterstützen und bevorzugt aushandeln, die Forward Secrecy bieten. Jedoch SOLLTEN TLS 1.2-Implementierungen KEINE Cipher-Suites aushandeln, die auf einer ephemeren Finite-Field Diffie-Hellman-Schlüsselvereinbarung basieren (d. h. "TLS_DHE_*"-Suiten). Dies wird durch die bekannte Fragilität der Konstruktion (siehe [RACCOON]) und die Einschränkung bei der Aushandlung begründet, einschließlich der Verwendung von [RFC7919], die nur eine sehr begrenzte Akzeptanz gefunden hat.

  Grund: Forward Secrecy (manchmal auch "Perfect Forward Secrecy" genannt) verhindert die Wiederherstellung von Informationen, die mit älteren Sitzungsschlüsseln verschlüsselt wurden, und begrenzt so die Menge an Daten, die in die Vergangenheit entschlüsselt werden können, wenn ein Angriff erfolgreich ist. Siehe Abschnitte 7.3 und 7.4 für eine detaillierte Diskussion.

4.2. Cipher-Suites für TLS 1.2

Angesichts der vorstehenden Überlegungen wird die Implementierung und Bereitstellung der folgenden Cipher-Suites EMPFOHLEN:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Da es sich bei diesen um Authenticated Encryption with Associated Data (AEAD)-Algorithmen [RFC5116] handelt, werden diese Cipher-Suites nur in TLS 1.2 und nicht in früheren Protokollversionen unterstützt.

Typischerweise muss die Reihenfolge der Suiten in der Serversoftware explizit konfiguriert werden, um diese Suiten zu bevorzugen. Es wäre ideal, wenn Serversoftware-Implementierungen diese Suiten standardmäßig bevorzugen würden.

Einige Geräte verfügen über Hardwareunterstützung für AES Counter Mode with CBC-MAC (AES-CCM), aber nicht für AES Galois/Counter Mode (AES-GCM), sodass sie die vorstehenden Empfehlungen zu Cipher-Suites nicht befolgen können. Es gibt sogar Geräte, die Public-Key-Kryptographie überhaupt nicht unterstützen, aber diese liegen vollständig außerhalb des Geltungsbereichs.

Eine Cipher-Suite, die im Cipher Block Chaining (CBC)-Modus arbeitet (z. B. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256), SOLLTE NICHT verwendet werden, es sei denn, die encrypt_then_mac-Erweiterung [RFC7366] wird ebenfalls erfolgreich ausgehandelt. Diese Anforderung gilt sowohl für Client- als auch für Server-Implementierungen.

Bei der Verwendung von ECDSA-Signaturen zur Authentifizierung von TLS-Peers wird EMPFOHLEN, dass Implementierungen die NIST-Kurve P-256 verwenden. Darüber hinaus wird EMPFOHLEN, dass Implementierungen "deterministisches ECDSA" implementieren, wie in [RFC6979] spezifiziert und in Übereinstimmung mit den Empfehlungen von [RFC8446], um vorhersehbare oder wiederholte Nonces zu vermeiden (die den langfristigen Signaturschlüssel offenbaren könnten).

Beachten Sie, dass Implementierungen von "deterministischem ECDSA" gerade wegen ihres Determinismus anfällig für bestimmte Seitenkanal- und Fehlerinjektionsangriffe sein können. Während die meisten in der Literatur beschriebenen Fehlerinjektionsangriffe physischen Zugriff auf das Gerät voraussetzen (und daher in Internet of Things (IoT)-Bereitstellungen mit schwacher oder fehlender physischer Sicherheit relevanter sind), können einige aus der Ferne durchgeführt werden [Poddebniak2017], z. B. in Form von Rowhammer-Varianten [Kim2014]. In Bereitstellungen, in denen Seitenkanal- und Fehlerinjektionsangriffe ein Problem darstellen, können Implementierungsstrategien, die Zufälligkeit und Determinismus kombinieren (z. B. wie in [CFRG-DET-SIGS] beschrieben), verwendet werden, um das Risiko einer erfolgreichen Extraktion des Signaturschlüssels zu vermeiden.

4.2.1. Implementierungsdetails

Clients SOLLTEN TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 als ersten Vorschlag an jeden Server aufnehmen. Server MÜSSEN diese Cipher-Suite schwächeren Cipher-Suites vorziehen, wann immer sie vorgeschlagen wird, auch wenn sie nicht der erste Vorschlag ist. Clients steht es natürlich frei, stärkere Cipher-Suites vorzuschlagen, z. B. unter Verwendung von AES-256; wenn sie dies tun, SOLLTE der Server die stärkere Cipher-Suite vorziehen, es sei denn, es gibt zwingende Gründe (z. B. stark beeinträchtigte Leistung), sich anders zu entscheiden.

Die vorherige Version der TLS-Empfehlungen [RFC7525] erlaubte implizit die alte Mandatory-to-Implement-Cipher-Suite von RFC 5246, TLS_RSA_WITH_AES_128_CBC_SHA. Zum Zeitpunkt des Schreibens bietet diese Cipher-Suite keine zusätzliche Interoperabilität, außer mit sehr alten Clients. Wie bei anderen Cipher-Suites, die keine Forward Secrecy bieten, SOLLTEN Implementierungen diese Cipher-Suite NICHT unterstützen. Andere Anwendungsprotokolle spezifizieren andere Cipher-Suites als Mandatory-to-Implement (MTI).

[RFC8422] erlaubt es Clients und Servern, ECDH-Parameter (Kurven) auszuhandeln. Clients und Server SOLLTEN die "Supported Elliptic Curves Extension" [RFC8422] einschließen. Clients und Server SOLLTEN die NIST-Kurve P-256 (secp256r1) [RFC8422] und X25519 (x25519) [RFC7748] unterstützen. Beachten Sie, dass [RFC8422] alles außer dem unkomprimierten Punktformat veraltet. Wenn der Client daher eine ec_point_formats-Erweiterung sendet, MUSS die ECPointFormatList ein einzelnes Element enthalten, "uncompressed".

4.3. Cipher-Suites für TLS 1.3

Dieses Dokument spezifiziert keine Cipher-Suites für TLS 1.3. Leser werden auf Abschnitt 9.1 von [RFC8446] für Cipher-Suite-Empfehlungen verwiesen.

4.4. Grenzen für die Schlüsselnutzung

Alle Chiffren haben eine Obergrenze für die Menge an Daten, die mit einem bestimmten Schlüssel sicher geschützt werden können. Im Fall von AEAD-Cipher-Suites werden für jeden Schlüssel zwei separate Grenzen eingehalten:

1. Vertraulichkeitsgrenze (Confidentiality Limit, CL), d. h. die Anzahl der Datensätze, die verschlüsselt werden können.

2. Integritätsgrenze (Integrity Limit, IL), d. h. die Anzahl der Datensätze, die bei der Authentifizierung fehlschlagen dürfen.

Letzteres gilt für DTLS (und auch für QUIC), aber nicht für TLS selbst, da TLS-Verbindungen beim ersten Entschlüsselungsfehler abgerissen werden.

Wenn sich ein Absender der CL nähert, SOLLTE die Implementierung einen neuen Handshake initiieren (in TLS 1.3 kann dies durch Senden einer KeyUpdate-Nachricht auf der etablierten Sitzung erreicht werden), um den Sitzungsschlüssel zu rotieren. Wenn ein Empfänger die IL erreicht hat, SOLLTE die Implementierung die Verbindung schließen. Obwohl diese Empfehlungen eine gute Praxis sind, müssen Implementierer sich bewusst sein, dass dies in Protokollen, die auf TLS/DTLS aufbauen, nicht immer einfach zu erreichen ist, ohne eine Koordination über Schichtgrenzen hinweg einzuführen. Siehe Abschnitt 6 von [RFC9001] für ein Beispiel der Zusammenarbeit, die in QUIC zwischen Krypto- und Transportschichten erforderlich war, um Schlüsselaktualisierungen zu unterstützen. Beachten Sie, dass Anwendungsprotokolle diese Methode im Allgemeinen aufgrund ihrer eingeschränkteren Interaktion mit TLS/DTLS möglicherweise nicht emulieren können. Aufgrund dieser Komplexität sind diese Empfehlungen nicht verbindlich.

Für alle TLS 1.3-Cipher-Suites werden Leser auf Abschnitt 5.5 von [RFC8446] für die Werte von CL und IL verwiesen. Für alle DTLS 1.3-Cipher-Suites werden Leser auf Abschnitt 4.5.3 von [RFC9147] verwiesen.

Für alle AES-GCM-Cipher-Suites, die in diesem Dokument für TLS 1.2 und DTLS 1.2 empfohlen werden, kann CL abgeleitet werden, indem die entsprechenden Parameter in die Ungleichungen in Abschnitt 6.1 von [AEAD-LIMITS] eingesetzt werden, die für teilweise implizite zufällige Nonces gelten, d. h. die in TLS 1.2 verwendete Nonce-Konstruktion. Obwohl die erhaltenen Zahlen etwas höher sind als die von TLS 1.3, wird EMPFOHLEN, dieselbe Grenze von 2^24,5 Datensätzen für beide Versionen zu verwenden.

Für alle AES-GCM-Cipher-Suites, die für DTLS 1.2 empfohlen werden, beträgt IL (erhalten aus denselben oben genannten Ungleichungen) 2^28.

4.5. Länge des öffentlichen Schlüssels

Bei der Verwendung der in diesem Dokument empfohlenen Cipher-Suites werden im TLS-Handshake normalerweise zwei öffentliche Schlüssel verwendet: einer für die Diffie-Hellman-Schlüsselvereinbarung und einer für die Serverauthentifizierung. Wenn ein Client-Zertifikat verwendet wird, kommt ein dritter öffentlicher Schlüssel hinzu.

Bei Schlüsselaustausch basierend auf modularen exponentiellen (MODP) Diffie-Hellman-Gruppen ("DHE"-Cipher-Suites) sind DH-Schlüssellängen von mindestens 2048 Bit ERFORDERLICH.

Grund: Aus verschiedenen Gründen werden DH-Schlüssel in der Praxis typischerweise in Längen generiert, die Zweierpotenzen sind (z. B. 2^10 = 1024 Bit, 2^11 = 2048 Bit, 2^12 = 4096 Bit). Da ein DH-Schlüssel von 1228 Bit nur in etwa einem symmetrischen Schlüssel von 80 Bit entsprechen würde [RFC3766], ist es besser, Schlüssel zu verwenden, die länger sind als dies für die "DHE"-Familie von Cipher-Suites. Ein DH-Schlüssel von 1926 Bit würde in etwa einem symmetrischen Schlüssel von 100 Bit entsprechen [RFC3766]. Ein DH-Schlüssel von 2048 Bit (entsprechend einem symmetrischen Schlüssel von 112 Bit) ist das Minimum, das von der zum Zeitpunkt des Schreibens neuesten Revision von [NIST.SP.800-56A] erlaubt ist (siehe insbesondere Anhang D dieses Dokuments).

Wie in [RFC3766] erwähnt, würde die Korrektur für das Aufkommen der TWIRL-Maschine (The Weizmann Institute Relation Locator) [TWIRL] implizieren, dass 1024-Bit-DH-Schlüssel etwa 61 Bit äquivalente Stärke ergeben und ein 2048-Bit-DH-Schlüssel etwa 92 Bit äquivalente Stärke ergeben würde. Der Logjam-Angriff [Logjam] zeigt weiter, dass 1024-Bit Diffie-Hellman-Parameter vermieden werden sollten.

In Bezug auf ECDH-Schlüssel werden Implementierer auf das IANA-Register "TLS Supported Groups" (früher als "EC Named Curve Registry" bekannt) innerhalb des Registers "Transport Layer Security (TLS) Parameters" [IANA_TLS] und insbesondere auf die "recommended" Gruppen verwiesen. Kurven von weniger als 224 Bit DÜRFEN NICHT verwendet werden. Diese Empfehlung steht im Einklang mit der neuesten Revision von [NIST.SP.800-56A].

Bei der Verwendung von RSA MÜSSEN Server sich mit Zertifikaten authentifizieren, die einen Modulus von mindestens 2048 Bit für den öffentlichen Schlüssel haben. Darüber hinaus wird die Verwendung des SHA-256-Hash-Algorithmus EMPFOHLEN und SHA-1 oder MD5 DÜRFEN NICHT verwendet werden [RFC9155] (für weitere Details siehe auch [CAB-Baseline], deren aktuelle Version zum Zeitpunkt des Schreibens 1.8.4 ist). Clients MÜSSEN Servern mitteilen, dass sie SHA-256 anfordern, indem sie die in TLS 1.2 definierte Erweiterung "Signature Algorithms" verwenden. Für TLS 1.3 wird dieselbe Anforderung bereits durch [RFC8446] spezifiziert.

4.6. Abgeschnittener HMAC

Implementierungen DÜRFEN die in Abschnitt 7 von [RFC6066] definierte Erweiterung Truncated HMAC NICHT verwenden.

Grund: Die Erweiterung gilt nicht für die oben empfohlenen AEAD-Cipher-Suites. Sie gilt jedoch für die meisten anderen TLS-Cipher-Suites. Ihre Verwendung hat sich in [PatersonRS11] als unsicher erwiesen.