Zum Hauptinhalt springen

RFC 8314 - Klartext als veraltet betrachtet: Verwendung von TLS für E-Mail-Submission und -Zugriff

  • Status: Proposed Standard
  • Veröffentlicht: January 2018
  • Stream: IETF
  • Aktualisiert: RFC1939, RFC2595, RFC3501, RFC5068, RFC6186, RFC6409
  • Errata: Keine Errata

Dokumentinformationen​

  • RFC-Nummer: 8314
  • Titel: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
  • Autoren: K. Moore, C. Newman
  • Datum: January 2018
  • Kategorie: Best Current Practice
  • ISSN: 2070-1721

Zusammenfassung (Abstract)​

Dieses Dokument verlangt, dass E-Mail-Zugriffsprotokolle (POP, IMAP) und E-Mail-Submission-Protokolle (SMTP Submission) durch TLS (Transport Layer Security) gesichert werden und dass die Verwendung von Klartext für diese Protokolle abgelehnt wird.

Status dieses Memos​

Dieses Memo dokumentiert eine Internet Best Current Practice.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Gemeinschaft. Es wurde öffentlich geprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu BCPs finden sich in Section 2 von RFC 7841.

Informationen zum aktuellen Status dieses Dokuments, zu Errata und dazu, wie Feedback gegeben werden kann, sind unter https://www.rfc-editor.org/info/rfc8314 verfügbar.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

Dieses Dokument unterliegt BCP 78 und den Legal Provisions des IETF Trust zu IETF-Dokumenten (https://trustee.ietf.org/license-info), die zum Veröffentlichungsdatum dieses Dokuments gelten. Bitte prüfen Sie diese Dokumente sorgfältig, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Aus diesem Dokument extrahierte Codekomponenten müssen den Text der Simplified BSD License gemäß Section 4.e der Trust Legal Provisions enthalten und werden ohne Gewährleistung bereitgestellt, wie in der Simplified BSD License beschrieben.

Inhaltsverzeichnis​

  1. Einleitung
  2. Terminologie
  3. Ablehnung von Klartext
  4. Spezifische Protokolle
  5. Sicherheitsbetrachtungen
  6. IANA-Erwägungen
  7. Referenzen

1. Einleitung​

Die Verwendung von Klartextkommunikation (unverschlüsselt) für E-Mail-Protokolle (POP, IMAP, SMTP Submission) setzt Benutzeranmeldeinformationen und E-Mail-Inhalte dem Abhören aus. Dieses Dokument spezifiziert, dass TLS für diese Protokolle verwendet werden MUST.

2. 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 so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, und zwar nur, wenn sie in Großbuchstaben erscheinen.

3. Ablehnung von Klartext​

3.1. Mail User Agents (MUAs)​

MUAs MUST TLS für alle E-Mail-Submission- und -Zugriffssitzungen konfigurieren.

3.2. Mail Service Providers (MSPs)​

MSPs MUST TLS für alle E-Mail-Submission- und -Zugriffsdienste bereitstellen. MSPs SHOULD Klartextzugriff ablehnen und deaktivieren.

3.3. Verwendung von TLS 1.2 oder höher​

Implementierungen MUST TLS 1.2 [RFC5246] oder höher unterstützen.

4. Spezifische Protokolle​

4.1. IMAP​

IMAP-Server MUST implizites TLS auf Port 993 unterstützen. STARTTLS auf Port 143 ist ebenfalls zulässig, aber implizites TLS wird bevorzugt.

4.2. POP​

POP-Server MUST implizites TLS auf Port 995 unterstützen. STARTTLS auf Port 110 ist ebenfalls zulässig, aber implizites TLS wird bevorzugt.

4.3. SMTP Submission​

SMTP-Submission-Server MUST implizites TLS auf Port 465 unterstützen. STARTTLS auf Port 587 ist ebenfalls zulässig.

5. Sicherheitsbetrachtungen​

Dieses Dokument befasst sich mit den Sicherheitsrisiken der Verwendung von Klartext für E-Mail-Protokolle. Es schreibt die Verwendung von TLS vor, um Vertraulichkeit und Integrität zu schützen.

6. IANA-Erwägungen​

Dieses Dokument erfordert keine IANA-Aktionen.

7. Referenzen​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

Adressen der Autoren

Keith Moore Network Heretics

Email: [email protected]

Chris Newman Oracle

Email: [email protected]