1. Introduction

L'objectif principal de TLS est de fournir un canal sécurisé (Secure Channel) entre deux pairs communicants; la seule exigence du transport sous-jacent est un flux de données fiable et ordonné. Plus précisément, le canal sécurisé doit fournir les propriétés suivantes:

• Authentication (Authentification): Le côté serveur du canal est toujours authentifié; le côté client est authentifié de manière optionnelle. L'authentification peut se faire via la cryptographie asymétrique (Asymmetric Cryptography) (par exemple, RSA [RSA], l'algorithme de signature numérique à courbe elliptique (ECDSA) [ECDSA], ou l'algorithme de signature numérique à courbe Edwards (EdDSA) [RFC8032]) ou une clé pré-partagée symétrique (PSK).

• Confidentiality (Confidentialité): Les données envoyées sur le canal après l'établissement ne sont visibles que par les points d'extrémité. TLS ne cache pas la longueur des données qu'il transmet, mais les points d'extrémité peuvent remplir les enregistrements TLS afin d'obscurcir les longueurs et améliorer la protection contre les techniques d'analyse de trafic.

• Integrity (Intégrité): Les données envoyées sur le canal après l'établissement ne peuvent pas être modifiées par des attaquants sans détection.

Ces propriétés doivent être vraies même face à un attaquant qui a un contrôle complet du réseau, comme décrit dans [RFC3552]. Voir l'Annexe E pour une déclaration plus complète des propriétés de sécurité pertinentes.

TLS se compose de deux composants principaux:

• Un protocole de négociation (Handshake Protocol) (Section 4) qui authentifie les parties communicantes, négocie les modes et paramètres cryptographiques, et établit le matériel de clé partagé. Le protocole de négociation est conçu pour résister à la falsification; un attaquant actif ne devrait pas être capable de forcer les pairs à négocier des paramètres différents de ceux qu'ils auraient si la connexion n'était pas attaquée.

• Un protocole d'enregistrement (Record Protocol) (Section 5) qui utilise les paramètres établis par le protocole de négociation pour protéger le trafic entre les pairs communicants. Le protocole d'enregistrement divise le trafic en une série d'enregistrements, chacun étant protégé indépendamment à l'aide des clés de trafic.

TLS est indépendant du protocole d'application; les protocoles de niveau supérieur peuvent se superposer de manière transparente sur TLS. Cependant, la norme TLS ne spécifie pas comment les protocoles ajoutent la sécurité avec TLS; comment initier la négociation TLS et comment interpréter les certificats d'authentification échangés sont laissés au jugement des concepteurs et implémenteurs de protocoles qui s'exécutent au-dessus de TLS.

Ce document définit TLS version 1.3. Bien que TLS 1.3 ne soit pas directement compatible avec les versions précédentes, toutes les versions de TLS incorporent un mécanisme de versionnement qui permet aux clients et serveurs de négocier de manière interopérable une version commune si elle est supportée par les deux pairs.

Ce document remplace et rend obsolètes les versions précédentes de TLS, y compris la version 1.2 [RFC5246]. Il rend également obsolète le mécanisme de ticket TLS défini dans [RFC5077] et le remplace par le mécanisme défini dans la Section 2.2. Comme TLS 1.3 change la façon dont les clés sont dérivées, il met à jour [RFC5705] comme décrit dans la Section 7.5. Il change également la manière dont les messages du protocole de statut de certificat en ligne (OCSP) sont transportés et met donc à jour [RFC6066] et rend obsolète [RFC6961] comme décrit dans la Section 4.4.2.1.

1.1 Conventions and Terminology (Conventions et 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 BCP 14 [RFC2119] [RFC8174] quand, et seulement quand, ils apparaissent en majuscules, comme montré ici.

Les termes suivants sont utilisés:

client: Le point d'extrémité qui initie la connexion TLS.

connection (connexion): Une connexion de couche transport entre deux points d'extrémité.

endpoint (point d'extrémité): Le client ou le serveur de la connexion.

handshake (négociation): Une négociation initiale entre client et serveur qui établit les paramètres de leurs interactions ultérieures au sein de TLS.

peer (pair): Un point d'extrémité. Lors de la discussion d'un point d'extrémité particulier, "peer" fait référence au point d'extrémité qui n'est pas le sujet de la discussion.

receiver (récepteur): Un point d'extrémité qui reçoit des enregistrements.

sender (émetteur): Un point d'extrémité qui transmet des enregistrements.

server (serveur): Le point d'extrémité qui n'a pas initié la connexion TLS.

1.2 Major Differences from TLS 1.2 (Différences majeures avec TLS 1.2)

Voici une liste des principales différences fonctionnelles entre TLS 1.2 et TLS 1.3. Elle n'est pas exhaustive, et il existe de nombreuses différences mineures.

• La liste des algorithmes de chiffrement symétrique supportés a été élaguée de tous les algorithmes considérés comme hérités. Ceux qui restent sont tous des algorithmes de chiffrement authentifié avec données associées (AEAD). Le concept de suite de chiffrement (Cipher Suite) a été modifié pour séparer les mécanismes d'authentification et d'échange de clés de l'algorithme de protection d'enregistrement (y compris la longueur de clé secrète) et d'un hachage à utiliser avec la fonction de dérivation de clé et le code d'authentification de message de négociation (MAC).

• Un mode à zéro temps d'aller-retour (0-RTT) a été ajouté, économisant un aller-retour lors de l'établissement de connexion pour certaines données d'application, au prix de certaines propriétés de sécurité.

• Les suites de chiffrement RSA statique et Diffie-Hellman ont été supprimées; tous les mécanismes d'échange de clés basés sur les clés publiques fournissent maintenant la confidentialité persistante (Forward Secrecy).

• Tous les messages de négociation après le ServerHello sont maintenant chiffrés. Le message EncryptedExtensions nouvellement introduit permet à diverses extensions précédemment envoyées en clair dans le ServerHello de bénéficier également de la protection de confidentialité.

• Les fonctions de dérivation de clés ont été repensées. La nouvelle conception permet une analyse plus facile par les cryptographes en raison de leurs propriétés améliorées de séparation de clés. La fonction de dérivation de clés d'extraction et d'expansion basée sur HMAC (HKDF) est utilisée comme primitive sous-jacente.

• La machine à états de négociation a été considérablement restructurée pour être plus cohérente et supprimer les messages superflus tels que ChangeCipherSpec (sauf lorsque nécessaire pour la compatibilité avec les middleboxes).

• Les algorithmes à courbe elliptique sont maintenant dans la spécification de base, et de nouveaux algorithmes de signature, tels que EdDSA, sont inclus. TLS 1.3 a supprimé la négociation du format de point en faveur d'un format de point unique pour chaque courbe.

• D'autres améliorations cryptographiques ont été apportées, notamment le changement du remplissage RSA pour utiliser le schéma de signature probabiliste RSA (RSASSA-PSS), et la suppression de la compression, de l'algorithme de signature numérique (DSA) et des groupes Diffie-Hellman éphémères (DHE) personnalisés.

• Le mécanisme de négociation de version TLS 1.2 a été déprécié en faveur d'une liste de versions dans une extension. Cela augmente la compatibilité avec les serveurs existants qui ont incorrectement implémenté la négociation de version.

• La reprise de session avec et sans état côté serveur ainsi que les suites de chiffrement basées sur PSK des versions TLS antérieures ont été remplacées par un seul nouvel échange PSK.

• Les références ont été mises à jour pour pointer vers les versions mises à jour des RFC (par exemple, RFC 5280 plutôt que RFC 3280).

1.3 Updates Affecting TLS 1.2 (Mises à jour affectant TLS 1.2)

Ce document définit plusieurs changements qui affectent optionnellement les implémentations de TLS 1.2, y compris celles qui ne supportent pas également TLS 1.3:

• Un mécanisme de protection contre la rétrogradation de version est décrit dans la Section 4.1.3.

• Les schémas de signature RSASSA-PSS sont définis dans la Section 4.2.3.

• L'extension ClientHello "supported_versions" peut être utilisée pour négocier la version de TLS à utiliser, de préférence au champ legacy_version du ClientHello.

• L'extension "signature_algorithms_cert" permet à un client d'indiquer quels algorithmes de signature il peut valider dans les certificats X.509.

De plus, ce document clarifie certaines exigences de conformité pour les versions antérieures de TLS; voir la Section 9.3.

---