Aller au contenu principal

RFC 8314 - Le texte en clair considéré comme obsolète: utilisation de TLS pour la soumission et l'accès au courrier

  • Statut: Proposed Standard
  • Publication: January 2018
  • Stream: IETF
  • Met à jour: RFC1939, RFC2595, RFC3501, RFC5068, RFC6186, RFC6409
  • Errata: Aucune errata

Informations sur le document​

  • Numéro RFC: 8314
  • Titre: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
  • Auteurs: K. Moore, C. Newman
  • Date: January 2018
  • Catégorie: Best Current Practice
  • ISSN: 2070-1721

Résumé (Abstract)​

Le présent document exige que les protocoles d'accès au courrier (POP, IMAP) et les protocoles de soumission de courrier (SMTP submission) soient sécurisés par TLS (Transport Layer Security) et que l'utilisation du texte en clair pour ces protocoles soit dépréciée.

État de ce mémo​

Ce mémo documente une Internet Best Current Practice.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). Des informations supplémentaires sur les BCP sont disponibles dans la Section 2 du RFC 7841.

Des informations sur l'état actuel de ce document, toute errata et la façon de fournir des retours sont disponibles à https://www.rfc-editor.org/info/rfc8314.

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

Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la Simplified BSD License décrit à la Section 4.e des Trust Legal Provisions et sont fournis sans garantie comme décrit dans la Simplified BSD License.

Table des matières​

  1. Introduction
  2. Terminologie
  3. Dépréciation du texte en clair
  4. Protocoles spécifiques
  5. Considérations de sécurité
  6. Considérations IANA
  7. Références

1. Introduction​

L'utilisation d'une communication en clair (non chiffrée) pour les protocoles de messagerie (POP, IMAP, SMTP Submission) expose les identifiants utilisateur et le contenu du courrier à l'écoute. Le présent document spécifie que TLS MUST être utilisé pour ces protocoles.

2. Terminologie​

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsqu'ils apparaissent en majuscules, et uniquement dans ce cas.

3. Dépréciation du texte en clair​

3.1. Agents utilisateurs de messagerie (MUAs)​

Les MUA MUST configurer TLS pour toutes les sessions de soumission et d'accès au courrier.

3.2. Fournisseurs de services de messagerie (MSPs)​

Les MSP MUST fournir TLS pour tous les services de soumission et d'accès au courrier. Les MSP SHOULD déprécier et désactiver l'accès en clair.

3.3. Utilisation de TLS 1.2 ou supérieur​

Les mises en œuvre MUST prendre en charge TLS 1.2 [RFC5246] ou supérieur.

4. Protocoles spécifiques​

4.1. IMAP​

Les serveurs IMAP MUST prendre en charge le TLS implicite sur le port 993. STARTTLS sur le port 143 est également autorisé, mais le TLS implicite est préféré.

4.2. POP​

Les serveurs POP MUST prendre en charge le TLS implicite sur le port 995. STARTTLS sur le port 110 est également autorisé, mais le TLS implicite est préféré.

4.3. SMTP Submission​

Les serveurs SMTP Submission MUST prendre en charge le TLS implicite sur le port 465. STARTTLS sur le port 587 est également autorisé.

5. Considérations de sécurité​

Le présent document traite des risques de sécurité liés à l'utilisation du texte en clair pour les protocoles de messagerie. Il impose l'utilisation de TLS pour protéger la confidentialité et l'intégrité.

6. Considérations IANA​

Le présent document n'exige aucune action de l'IANA.

7. Références​

  • [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.

Adresses des auteurs

Keith Moore Network Heretics

Email: [email protected]

Chris Newman Oracle

Email: [email protected]