5. Anwendbarkeitserklärung

Die Empfehlungen dieses Dokuments gelten in erster Linie für die Implementierung und Bereitstellung von Anwendungsprotokollen, die heute im Internet am häufigsten mit TLS und DTLS verwendet werden. Beispiele sind unter anderem:

• Web-Software und -Dienste, die HTTP-Verkehr mit TLS schützen möchten.

• E-Mail-Software und -Dienste, die IMAP-, Post Office Protocol Version 3 (POP3)- oder SMTP-Verkehr mit TLS schützen möchten.

• Instant-Messaging-Software und -Dienste, die Extensible Messaging and Presence Protocol (XMPP)- oder Internet Relay Chat (IRC)-Verkehr mit TLS schützen möchten.

• Echtzeit-Multimedia-Software und -Dienste, die Secure Realtime Transport Protocol (SRTP)-Verkehr mit DTLS schützen möchten.

Dieses Dokument ändert nicht die Implementierungs- und Bereitstellungsempfehlungen (z. B. Mandatory-to-Implement-Cipher-Suites), die von bestehenden Anwendungsprotokollen vorgeschrieben sind, die TLS oder DTLS verwenden. Wenn die Community, die ein solches Anwendungsprotokoll verwendet, ihre Nutzung von TLS oder DTLS modernisieren möchte, um sie mit den hier empfohlenen Best Practices in Einklang zu bringen, muss sie die Definition des bestehenden Anwendungsprotokolls explizit aktualisieren (ein Beispiel ist [RFC7590], das [RFC6120] aktualisiert).

Von Designern neuer Anwendungsprotokolle, die über den Internet-Standards-Prozess [RFC2026] entwickelt werden, wird erwartet, dass sie mindestens die hier empfohlenen Best Practices einhalten, es sei denn, sie liefern eine Dokumentation zwingender Gründe, die eine solche Einhaltung verhindern würden (z. B. weit verbreitete Bereitstellung auf eingeschränkten Geräten, denen die Unterstützung für die erforderlichen Algorithmen fehlt).

Obwohl viele der hier gegebenen Empfehlungen auch für QUIC gelten können, soweit es das TLS 1.3-Handshake-Protokoll verwendet, liegen QUIC und ähnliche sichere Transportprotokolle nicht im Geltungsbereich dieses Dokuments. Für QUIC im Speziellen werden Leser auf Abschnitt 9.2 von [RFC9001] verwiesen.

Dieses Dokument befasst sich nicht mit der Verwendung von TLS in Netzwerken mit eingeschränkten Knoten [RFC7228]. Für Empfehlungen zur Profilierung von TLS und DTLS für kleine Geräte mit starken Einschränkungen hinsichtlich Strom-, Speicher- und Verarbeitungsressourcen wird der Leser auf [RFC7925] und [IOT-PROFILE] verwiesen.

5.1. Sicherheitsdienste

Dieses Dokument bietet Empfehlungen für ein Publikum, das seine Kommunikation mit TLS sichern möchte, um folgende Ziele zu erreichen:

Vertraulichkeit: Die gesamte Kommunikation der Anwendungsschicht wird verschlüsselt, mit dem Ziel, dass keine Partei sie entschlüsseln kann, außer dem beabsichtigten Empfänger.

Datenintegrität: Jede Änderung an der Kommunikation während der Übertragung ist für den Empfänger erkennbar.

Authentifizierung: Ein Endpunkt der TLS-Kommunikation wird als die beabsichtigte Entität authentifiziert, mit der kommuniziert werden soll.

In Bezug auf die Authentifizierung ermöglicht TLS die Authentifizierung eines oder beider Endpunkte der Kommunikation. Im Kontext der opportunistischen Sicherheit [RFC7435] wird TLS manchmal ohne Authentifizierung verwendet. Wie in Abschnitt 5.2 diskutiert, liegen Überlegungen zur opportunistischen Sicherheit nicht im Geltungsbereich dieses Dokuments.

Wenn Bereitsteller von den in diesem Dokument gegebenen Empfehlungen abweichen, müssen sie sich bewusst sein, dass sie den Zugriff auf einen der oben genannten Sicherheitsdienste verlieren könnten.

Dieses Dokument gilt nur für Umgebungen, in denen Vertraulichkeit erforderlich ist. Es erfordert Algorithmen und Konfigurationsoptionen, die das Geheimnis der Daten während der Übertragung durchsetzen.

Dieses Dokument geht auch davon aus, dass der Schutz der Datenintegrität immer eines der Ziele einer Bereitstellung ist. In Fällen, in denen Integrität nicht erforderlich ist, macht es keinen Sinn, TLS überhaupt zu verwenden. Es gibt Angriffe gegen den alleinigen Schutz der Vertraulichkeit, die den Mangel an Integrität nutzen, um auch die Vertraulichkeit zu brechen (siehe z. B. [DegabrieleP07] im Kontext von IPsec).

Dieses Dokument richtet sich an Anwendungsprotokolle, die im Internet am häufigsten mit TLS und DTLS verwendet werden. Typischerweise erfordert jede Kommunikation zwischen TLS-Clients und TLS-Servern alle drei oben genannten Sicherheitsdienste. Dies gilt insbesondere dann, wenn TLS-Clients User Agents wie Webbrowser oder E-Mail-Clients sind.

Dieses Dokument befasst sich nicht mit selteneren Bereitstellungsszenarien, in denen eine der oben genannten drei Eigenschaften nicht gewünscht ist, wie z. B. der in Abschnitt 5.2 beschriebene Anwendungsfall. Als ein weiteres Szenario, in dem Vertraulichkeit nicht erforderlich ist, betrachten Sie ein überwachtes Netzwerk, in dem die für die jeweilige Verkehrsdomäne verantwortlichen Behörden vollen Zugriff auf den unverschlüsselten Verkehr (Klartext) benötigen und in dem die Benutzer zusammenarbeiten und ihren Verkehr im Klartext senden.

5.2. Opportunistische Sicherheit

Es gibt mehrere wichtige Szenarien, in denen die Verwendung von TLS optional ist, d. h. der Client entscheidet dynamisch ("opportunistisch"), ob er TLS mit einem bestimmten Server verwendet oder im Klartext verbindet. Diese Praxis, oft als "opportunistische Sicherheit" bezeichnet, wird ausführlich in [RFC7435] beschrieben und ist oft durch den Wunsch nach Abwärtskompatibilität mit Legacy-Bereitstellungen motiviert.

In diesen Szenarien könnten einige der Empfehlungen dieses Dokuments zu streng sein, da deren Einhaltung zu einem Rückfall auf Klartext führen könnte, ein Ergebnis, das schlechter ist als die Verwendung von TLS mit einer veralteten Protokollversion oder Cipher-Suite.