5. Déclaration d'applicabilité

Les recommandations de ce document s'appliquent principalement à l'implémentation et au déploiement des protocoles d'application qui sont le plus couramment utilisés avec TLS et DTLS sur Internet aujourd'hui. Les exemples incluent, mais ne sont pas limités à :

• Logiciels et services Web qui souhaitent protéger le trafic HTTP avec TLS.

• Logiciels et services de messagerie qui souhaitent protéger le trafic IMAP, Post Office Protocol version 3 (POP3) ou SMTP avec TLS.

• Logiciels et services de messagerie instantanée qui souhaitent protéger le trafic Extensible Messaging and Presence Protocol (XMPP) ou Internet Relay Chat (IRC) avec TLS.

• Logiciels et services multimédias en temps réel qui souhaitent protéger le trafic Secure Realtime Transport Protocol (SRTP) avec DTLS.

Ce document ne modifie pas les recommandations d'implémentation et de déploiement (par exemple, les suites de chiffrement obligatoires à implémenter) prescrites par les protocoles d'application existants qui utilisent TLS ou DTLS. Si la communauté qui utilise un tel protocole d'application souhaite moderniser son utilisation de TLS ou DTLS pour être cohérente avec les meilleures pratiques recommandées ici, elle doit mettre à jour explicitement la définition du protocole d'application existant (un exemple est [RFC7590], qui met à jour [RFC6120]).

Les concepteurs de nouveaux protocoles d'application développés via le processus de normalisation Internet [RFC2026] sont censés au minimum se conformer aux meilleures pratiques recommandées ici, à moins qu'ils ne fournissent une documentation de raisons impérieuses qui empêcheraient une telle conformité (par exemple, un déploiement généralisé sur des appareils contraints qui manquent de support pour les algorithmes nécessaires).

Bien que bon nombre des recommandations fournies ici puissent également s'appliquer à QUIC dans la mesure où il utilise le protocole de handshake TLS 1.3, QUIC et d'autres protocoles de transport sécurisés similaires ne sont pas concernés par ce document. Pour QUIC spécifiquement, les lecteurs sont renvoyés à la section 9.2 de [RFC9001].

Ce document ne traite pas de l'utilisation de TLS dans les réseaux de nœuds contraints [RFC7228]. Pour des recommandations concernant le profilage de TLS et DTLS pour les petits appareils avec de sévères contraintes d'alimentation, de mémoire et de ressources de traitement, le lecteur est renvoyé à [RFC7925] et [IOT-PROFILE].

5.1. Services de sécurité

Ce document fournit des recommandations pour un public qui souhaite sécuriser ses communications avec TLS pour atteindre les objectifs suivants :

Confidentialité : toutes les communications de la couche application sont chiffrées dans le but qu'aucune partie ne puisse les déchiffrer à l'exception du destinataire prévu.

Intégrité des données : toute modification apportée à la communication en transit est détectable par le destinataire.

Authentification : un point de terminaison de la communication TLS est authentifié comme l'entité prévue avec laquelle communiquer.

En ce qui concerne l'authentification, TLS permet l'authentification de l'un ou des deux points de terminaison de la communication. Dans le contexte de la sécurité opportuniste [RFC7435], TLS est parfois utilisé sans authentification. Comme discuté à la section 5.2, les considérations relatives à la sécurité opportuniste ne sont pas concernées par ce document.

Si les déployeurs s'écartent des recommandations données dans ce document, ils doivent être conscients qu'ils pourraient perdre l'accès à l'un des services de sécurité susmentionnés.

Ce document s'applique uniquement aux environnements où la confidentialité est requise. Il nécessite des algorithmes et des options de configuration qui appliquent le secret des données en transit.

Ce document suppose également que la protection de l'intégrité des données est toujours l'un des objectifs d'un déploiement. Dans les cas où l'intégrité n'est pas requise, il n'est pas logique d'utiliser TLS en premier lieu. Il existe des attaques contre la protection de la confidentialité seule qui utilisent le manque d'intégrité pour briser également la confidentialité (voir, par exemple, [DegabrieleP07] dans le contexte d'IPsec).

Ce document s'adresse aux protocoles d'application qui sont le plus couramment utilisés sur Internet avec TLS et DTLS. Généralement, toute communication entre les clients TLS et les serveurs TLS nécessite les trois services de sécurité ci-dessus. Cela est particulièrement vrai lorsque les clients TLS sont des agents utilisateurs comme les navigateurs Web ou les clients de messagerie.

Ce document ne traite pas des scénarios de déploiement plus rares où l'une des trois propriétés ci-dessus n'est pas souhaitée, comme le cas d'utilisation décrit à la section 5.2. Comme autre scénario où la confidentialité n'est pas nécessaire, considérez un réseau surveillé où les autorités responsables du domaine de trafic respectif nécessitent un accès complet au trafic non chiffré (texte clair) et où les utilisateurs collaborent et envoient leur trafic en clair.

5.2. Sécurité opportuniste

Il existe plusieurs scénarios importants dans lesquels l'utilisation de TLS est facultative, c'est-à-dire que le client décide dynamiquement ("de manière opportuniste") d'utiliser ou non TLS avec un serveur particulier ou de se connecter en clair. Cette pratique, souvent appelée "sécurité opportuniste", est décrite longuement dans [RFC7435] et est souvent motivée par un désir de rétrocompatibilité avec les déploiements hérités.

Dans ces scénarios, certaines des recommandations de ce document pourraient être trop strictes, car s'y conformer pourrait entraîner un repli vers le texte clair, un résultat pire que l'utilisation de TLS avec une version de protocole ou une suite de chiffrement obsolète.