Zum Hauptinhalt springen

9. Compliance-Anforderungen (Compliance Requirements)

9.1. Obligatorisch zu implementierende Cipher Suites (Mandatory-to-Implement Cipher Suites)​

In Ermangelung eines Anwendungsprofil-Standards, der etwas anderes festlegt:

Eine TLS-konforme Anwendung MUSS (MUST) die Cipher Suite TLS_AES_128_GCM_SHA256 [GCM] implementieren und SOLLTE (SHOULD) die Cipher Suites TLS_AES_256_GCM_SHA384 [GCM] und TLS_CHACHA20_POLY1305_SHA256 [RFC8439] implementieren (siehe Anhang B.4).

Eine TLS-konforme Anwendung MUSS (MUST) digitale Signaturen mit rsa_pkcs1_sha256 (für Zertifikate), rsa_pss_rsae_sha256 (für CertificateVerify und Zertifikate) und ecdsa_secp256r1_sha256 unterstützen. Eine TLS-konforme Anwendung MUSS (MUST) Schlüsselaustausch mit secp256r1 (NIST P-256) unterstützen und SOLLTE (SHOULD) Schlüsselaustausch mit X25519 [RFC7748] unterstützen.

9.2. Obligatorisch zu implementierende Erweiterungen (Mandatory-to-Implement Extensions)​

In Ermangelung eines Anwendungsprofil-Standards, der etwas anderes festlegt, MUSS (MUST) eine TLS-konforme Anwendung die folgenden TLS-Erweiterungen implementieren:

  • Supported Versions (supported_versions; Abschnitt 4.2.1)
  • Cookie (cookie; Abschnitt 4.2.2)
  • Signature Algorithms (signature_algorithms; Abschnitt 4.2.3)
  • Signature Algorithms Certificate (signature_algorithms_cert; Abschnitt 4.2.3)
  • Negotiated Groups (supported_groups; Abschnitt 4.2.7)
  • Key Share (key_share; Abschnitt 4.2.8)
  • Server Name Indication (server_name; Abschnitt 3 von [RFC6066])

Alle Implementierungen MÜSSEN (MUST) diese Erweiterungen senden und verwenden, wenn sie anwendbare Funktionen anbieten:

  • supported_versions ist ERFORDERLICH (REQUIRED) für alle ClientHello-, ServerHello- und HelloRetryRequest-Nachrichten.

  • signature_algorithms ist ERFORDERLICH für Zertifikatauthentifizierung.

  • supported_groups ist ERFORDERLICH für ClientHello-Nachrichten, die DHE- oder ECDHE-Schlüsselaustausch verwenden.

  • key_share ist ERFORDERLICH für DHE- oder ECDHE-Schlüsselaustausch.

  • pre_shared_key ist ERFORDERLICH für PSK-Schlüsselvereinbarung.

  • psk_key_exchange_modes ist ERFORDERLICH für PSK-Schlüsselvereinbarung.

Ein Client wird als versuchend betrachtet, mit dieser Spezifikation zu verhandeln, wenn das ClientHello eine supported_versions-Erweiterung mit 0x0304 in seinem Körper enthält. Ein solches ClientHello MUSS (MUST) die folgenden Anforderungen erfüllen:

  • Wenn es keine pre_shared_key-Erweiterung enthält, MUSS (MUST) es sowohl eine signature_algorithms-Erweiterung als auch eine supported_groups-Erweiterung enthalten.

  • Wenn es eine supported_groups-Erweiterung enthält, MUSS (MUST) es auch eine key_share-Erweiterung enthalten, und umgekehrt. Ein leerer KeyShare.client_shares-Vektor ist zulässig.

Server, die ein ClientHello empfangen, das diesen Anforderungen nicht entspricht, MÜSSEN (MUST) den Handshake mit einem missing_extension-Alarm abbrechen.

Darüber hinaus MÜSSEN (MUST) alle Implementierungen die Verwendung der server_name-Erweiterung mit Anwendungen unterstützen, die sie verwenden können. Server KÖNNEN (MAY) von Clients verlangen, eine gültige server_name-Erweiterung zu senden. Server, die diese Erweiterung verlangen, SOLLTEN (SHOULD) auf ein ClientHello, dem eine server_name-Erweiterung fehlt, reagieren, indem sie die Verbindung mit einem missing_extension-Alarm beenden.

9.3. Protokollinvarianten (Protocol Invariants)​

Dieser Abschnitt beschreibt Invarianten, die TLS-Endpunkte und Middleboxen MÜSSEN (MUST) befolgen, um die Interoperabilität des Protokolls sicherzustellen.

TLS ist so konzipiert, dass es in einer Vielzahl von Netzwerkumgebungen verwendbar ist, einschließlich in Gegenwart von Middleboxen (z. B. Firewalls, Proxys und Netzwerkadressübersetzern), die das TLS-Protokoll nicht verstehen. Diese Middleboxen können bestimmte Aspekte von TLS-Verbindungen untersuchen und basierend auf ihren Beobachtungen Maßnahmen ergreifen. Um die Interoperabilität zu maximieren, MÜSSEN (MUST) TLS 1.3-Implementierungen bestimmte Protokollinvarianten einhalten, um sicherzustellen, dass Middleboxen die Verbindung nicht missverstehen.

Die folgenden sind wichtige Protokollinvarianten in TLS 1.3:

Record Layer-Invarianten​

Die TLS-Aufzeichnungsschicht MUSS (MUST) die folgenden Invarianten einhalten:

  1. Record-Version: Alle Datensätze (außer dem initialen ClientHello) MÜSSEN (MUST) legacy_record_version auf 0x0303 (TLS 1.2) setzen. Das initiale ClientHello KANN (MAY) dieses Feld auf 0x0301 (TLS 1.0) setzen, um maximale Kompatibilität zu gewährleisten.

  2. Inhaltstyp: Alle verschlüsselten Datensätze MÜSSEN (MUST) den äußeren Inhaltstyp auf application_data (23) setzen. Der tatsächliche Inhaltstyp befindet sich in TLSInnerPlaintext.

  3. Datensatzgröße: Unverschlüsselte TLSPlaintext-Datensätze DÜRFEN (MUST NOT) 2^14 Bytes nicht überschreiten. Verschlüsselte TLSCiphertext-Datensätze DÜRFEN 2^14 + 256 Bytes nicht überschreiten.

Handshake-Invarianten​

Der TLS-Handshake MUSS (MUST) die folgenden Invarianten einhalten:

  1. Erweiterungsreihenfolge: Die pre_shared_key-Erweiterung MUSS (MUST) die letzte Erweiterung im ClientHello sein.

  2. Nachrichtenreihenfolge: Handshake-Nachrichten MÜSSEN (MUST) in der in Abschnitt 4 angegebenen Reihenfolge gesendet werden.

  3. Schlüsseländerungsgrenzen: Bestimmte Nachrichten (ClientHello, EndOfEarlyData, ServerHello, Finished, KeyUpdate) MÜSSEN (MUST) mit Datensatzgrenzen übereinstimmen.

Middlebox-Kompatibilität​

Zur Kompatibilität mit Legacy-Middleboxen MÜSSEN TLS 1.3-Implementierungen:

  1. Einen change_cipher_spec-Datensatz (als separaten Datensatz) nach dem ServerHello senden (MUST), um Middlebox-Kompatibilität zu gewährleisten.

  2. Unerwartete change_cipher_spec-Datensätze (Wert 0x01), die während des Handshakes empfangen werden, ignorieren (MAY).

  3. 0x0303 als legacy_version im ServerHello verwenden (MUST).

Diese Invarianten stellen sicher, dass TLS 1.3-Verkehr für Middleboxen, die die neue Protokollversion nicht verstehen, ausreichend wie TLS 1.2 aussieht, wodurch der Einsatzerfolg maximiert wird.

Letztes Update am