1. Introduction (Einführung)

Das Hauptziel von TLS ist die Bereitstellung eines sicheren Kanals (Secure Channel) zwischen zwei kommunizierenden Peers; die einzige Anforderung an den zugrunde liegenden Transport ist ein zuverlässiger, geordneter Datenstrom. Konkret sollte der sichere Kanal die folgenden Eigenschaften bieten:

• Authentication (Authentifizierung): Die Serverseite des Kanals ist immer authentifiziert; die Clientseite ist optional authentifiziert. Die Authentifizierung kann über asymmetrische Kryptographie (Asymmetric Cryptography) (z.B. RSA [RSA], der Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA] oder der Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) oder einen symmetrischen vorgeteilten Schlüssel (PSK) erfolgen.

• Confidentiality (Vertraulichkeit): Die nach der Etablierung über den Kanal gesendeten Daten sind nur für die Endpunkte sichtbar. TLS verbirgt nicht die Länge der übertragenen Daten, aber die Endpunkte können TLS-Records auffüllen, um Längen zu verschleiern und den Schutz gegen Verkehrsanalysetechniken zu verbessern.

• Integrity (Integrität): Die nach der Etablierung über den Kanal gesendeten Daten können nicht von Angreifern unentdeckt modifiziert werden.

Diese Eigenschaften sollten auch dann gelten, wenn ein Angreifer vollständige Kontrolle über das Netzwerk hat, wie in [RFC3552] beschrieben. Siehe Anhang E für eine vollständigere Darstellung der relevanten Sicherheitseigenschaften.

TLS besteht aus zwei Hauptkomponenten:

• Ein Handshake-Protokoll (Handshake Protocol) (Abschnitt 4), das die kommunizierenden Parteien authentifiziert, kryptographische Modi und Parameter aushandelt und gemeinsames Schlüsselmaterial etabliert. Das Handshake-Protokoll ist so konzipiert, dass es Manipulationen widersteht; ein aktiver Angreifer sollte nicht in der Lage sein, die Peers zur Aushandlung anderer Parameter zu zwingen, als sie würden, wenn die Verbindung nicht angegriffen würde.

• Ein Record-Protokoll (Record Protocol) (Abschnitt 5), das die durch das Handshake-Protokoll etablierten Parameter verwendet, um den Verkehr zwischen den kommunizierenden Peers zu schützen. Das Record-Protokoll teilt den Verkehr in eine Reihe von Records auf, die jeweils unabhängig mit den Verkehrsschlüsseln geschützt werden.

TLS ist anwendungsprotokollunabhängig; Protokolle höherer Ebenen können transparent über TLS geschichtet werden. Der TLS-Standard spezifiziert jedoch nicht, wie Protokolle Sicherheit mit TLS hinzufügen; wie die TLS-Aushandlung initiiert wird und wie die ausgetauschten Authentifizierungszertifikate interpretiert werden, bleibt dem Urteil der Designer und Implementierer von Protokollen überlassen, die auf TLS laufen.

Dieses Dokument definiert TLS Version 1.3. Obwohl TLS 1.3 nicht direkt mit früheren Versionen kompatibel ist, enthalten alle Versionen von TLS einen Versionierungsmechanismus, der es Clients und Servern ermöglicht, interoperabel eine gemeinsame Version auszuhandeln, wenn diese von beiden Peers unterstützt wird.

Dieses Dokument ersetzt und macht frühere Versionen von TLS obsolet, einschließlich Version 1.2 [RFC5246]. Es macht auch den in [RFC5077] definierten TLS-Ticket-Mechanismus obsolet und ersetzt ihn durch den in Abschnitt 2.2 definierten Mechanismus. Da TLS 1.3 die Art und Weise ändert, wie Schlüssel abgeleitet werden, aktualisiert es [RFC5705] wie in Abschnitt 7.5 beschrieben. Es ändert auch die Art und Weise, wie Online Certificate Status Protocol (OCSP)-Nachrichten transportiert werden, und aktualisiert daher [RFC6066] und macht [RFC6961] obsolet, wie in Abschnitt 4.4.2.1 beschrieben.

1.1 Conventions and Terminology (Konventionen und Terminologie)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Die folgenden Begriffe werden verwendet:

client (Client): Der Endpunkt, der die TLS-Verbindung initiiert.

connection (Verbindung): Eine Transportschichtverbindung zwischen zwei Endpunkten.

endpoint (Endpunkt): Entweder der Client oder der Server der Verbindung.

handshake (Handshake): Eine anfängliche Aushandlung zwischen Client und Server, die die Parameter ihrer nachfolgenden Interaktionen innerhalb von TLS etabliert.

peer (Peer): Ein Endpunkt. Bei der Diskussion eines bestimmten Endpunkts bezieht sich "peer" auf den Endpunkt, der nicht Gegenstand der Diskussion ist.

receiver (Empfänger): Ein Endpunkt, der Records empfängt.

sender (Sender): Ein Endpunkt, der Records überträgt.

server (Server): Der Endpunkt, der die TLS-Verbindung nicht initiiert hat.

1.2 Major Differences from TLS 1.2 (Hauptunterschiede zu TLS 1.2)

Im Folgenden finden Sie eine Liste der wichtigsten funktionalen Unterschiede zwischen TLS 1.2 und TLS 1.3. Sie ist nicht erschöpfend, und es gibt viele kleinere Unterschiede.

• Die Liste der unterstützten symmetrischen Verschlüsselungsalgorithmen wurde von allen als veraltet geltenden Algorithmen bereinigt. Die verbleibenden sind alle Authenticated Encryption with Associated Data (AEAD)-Algorithmen. Das Konzept der Cipher Suite wurde geändert, um die Authentifizierungs- und Schlüsselaustausch-Mechanismen vom Record-Schutzalgorithmus (einschließlich der geheimen Schlüssellänge) und einem Hash zu trennen, der mit der Schlüsselableitungsfunktion und dem Handshake-Message Authentication Code (MAC) verwendet wird.

• Ein Zero Round-Trip Time (0-RTT)-Modus wurde hinzugefügt, der beim Verbindungsaufbau für einige Anwendungsdaten einen Roundtrip einspart, allerdings auf Kosten bestimmter Sicherheitseigenschaften.

• Statische RSA- und Diffie-Hellman-Cipher-Suites wurden entfernt; alle öffentlichen Schlüssel-basierten Schlüsselaustausch-Mechanismen bieten jetzt Forward Secrecy (Vorwärtsgeheimhaltung).

• Alle Handshake-Nachrichten nach dem ServerHello sind jetzt verschlüsselt. Die neu eingeführte EncryptedExtensions-Nachricht ermöglicht es verschiedenen Erweiterungen, die zuvor im ServerHello im Klartext gesendet wurden, ebenfalls Vertraulichkeitsschutz zu genießen.

• Die Schlüsselableitungsfunktionen wurden neu gestaltet. Das neue Design ermöglicht Kryptographen aufgrund ihrer verbesserten Schlüsseltrennungseigenschaften eine einfachere Analyse. Die HMAC-based Extract-and-Expand Key Derivation Function (HKDF) wird als zugrunde liegende Primitive verwendet.

• Der Handshake-Zustandsautomat wurde erheblich umstrukturiert, um konsistenter zu sein und überflüssige Nachrichten wie ChangeCipherSpec zu entfernen (außer wenn für Middlebox-Kompatibilität erforderlich).

• Elliptische Kurvenalgorithmen befinden sich jetzt in der Basisspezifikation, und neue Signaturalgorithmen wie EdDSA sind enthalten. TLS 1.3 entfernte die Punktformat-Aushandlung zugunsten eines einzelnen Punktformats für jede Kurve.

• Weitere kryptographische Verbesserungen wurden vorgenommen, einschließlich der Änderung des RSA-Paddings zur Verwendung des RSA Probabilistic Signature Scheme (RSASSA-PSS) und der Entfernung von Kompression, dem Digital Signature Algorithm (DSA) und benutzerdefinierten Ephemeral Diffie-Hellman (DHE)-Gruppen.

• Der TLS 1.2-Versionsaushandlungsmechanismus wurde zugunsten einer Versionsliste in einer Erweiterung veraltet. Dies erhöht die Kompatibilität mit bestehenden Servern, die die Versionsaushandlung falsch implementiert haben.

• Sitzungsfortsetzung mit und ohne serverseitigen Zustand sowie die PSK-basierten Cipher-Suites früherer TLS-Versionen wurden durch einen einzelnen neuen PSK-Austausch ersetzt.

• Referenzen wurden aktualisiert, um auf die aktualisierten Versionen von RFCs zu verweisen (z.B. RFC 5280 statt RFC 3280).

1.3 Updates Affecting TLS 1.2 (Aktualisierungen, die TLS 1.2 betreffen)

Dieses Dokument definiert mehrere Änderungen, die optional TLS 1.2-Implementierungen betreffen, einschließlich solcher, die TLS 1.3 nicht unterstützen:

• Ein Versions-Downgrade-Schutzmechanismus wird in Abschnitt 4.1.3 beschrieben.

• RSASSA-PSS-Signaturschemata werden in Abschnitt 4.2.3 definiert.

• Die "supported_versions" ClientHello-Erweiterung kann verwendet werden, um die zu verwendende TLS-Version auszuhandeln, vorzugsweise gegenüber dem legacy_version-Feld des ClientHello.

• Die "signature_algorithms_cert"-Erweiterung ermöglicht es einem Client anzugeben, welche Signaturalgorithmen er in X.509-Zertifikaten validieren kann.

Darüber hinaus klärt dieses Dokument einige Compliance-Anforderungen für frühere Versionen von TLS; siehe Abschnitt 9.3.

---