Aller au contenu principal

2. Conventions de notation (Notational Conventions)

Les mots clés "MUST (DOIT)", "MUST NOT (NE DOIT PAS)", "REQUIRED (REQUIS)", "SHALL (DOIT)", "SHALL NOT (NE DOIT PAS)", "SHOULD (DEVRAIT)", "SHOULD NOT (NE DEVRAIT PAS)", "RECOMMENDED (RECOMMANDÉ)", "NOT RECOMMENDED (NON RECOMMANDÉ)", "MAY (PEUT)", et "OPTIONAL (OPTIONNEL)" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Ce document utilise la terminologie établie dans [QUIC-TRANSPORT].

Par souci de concision, l'abréviation TLS est utilisée pour faire référence à TLS 1.3, bien que des versions plus récentes de TLS puissent être utilisées ; voir la section 4.2.

2.1. Aperçu de TLS (TLS Overview)​

TLS fournit un moyen pour deux points d'extrémité (endpoints) d'établir un moyen de communication sur un support non fiable (comme Internet). TLS permet l'authentification des pairs et fournit une protection de confidentialité et d'intégrité pour les messages échangés entre les points d'extrémité.

En interne, TLS est un protocole en couches, avec une structure illustrée dans la Figure 1.

         +-------------+------------+--------------+---------+
Couche   |             |            |  Données     |         |
de       | Handshake   |   Alerte   | d'application|   ...   |
contenu  |             |            |              |         |
         +-------------+------------+--------------+---------+
Couche   |                                                   |
d'enreg- |                   Enregistrement                 |
istrement|                                                   |
         +---------------------------------------------------+

Figure 1: Couches de TLS

Chaque message de la couche de contenu (par exemple, handshake, alerte et données d'application) est transporté par la couche d'enregistrement sous forme d'une série d'enregistrements TLS typés. Les enregistrements sont protégés cryptographiquement individuellement puis transmis sur un transport fiable (généralement TCP) qui assure l'ordonnancement et la garantie de livraison.

Le handshake d'échange de clés authentifié TLS se produit entre deux points d'extrémité : un client et un serveur. Le client initie l'échange et le serveur répond. Si l'échange de clés se termine avec succès, le client et le serveur conviennent tous deux d'un secret. TLS prend en charge à la fois les clés pré-partagées (PSK) et l'échange de clés Diffie-Hellman basé sur les corps finis ou les courbes elliptiques ((EC)DHE). Les PSK sont la base des données précoces (0-RTT) ; ces dernières fournissent une confidentialité persistante (FS) lorsque les clés (EC)DHE sont détruites. Ces deux modes peuvent également être combinés pour fournir une confidentialité persistante tout en utilisant une PSK pour l'authentification.

Après avoir terminé le handshake TLS, le client aura appris et authentifié l'identité du serveur et le serveur peut éventuellement avoir appris et authentifié l'identité du client. TLS prend en charge l'authentification du serveur et du client basée sur les certificats X.509 [RFC5280]. Lorsqu'un échange de clés PSK est utilisé (comme dans la reprise de session), la connaissance de la PSK est utilisée pour authentifier le pair.

L'échange de clés TLS résiste à la falsification par un attaquant et le secret partagé qu'il produit ne peut être contrôlé par aucun pair participant.

TLS fournit deux modes de handshake de base qui intéressent QUIC :

  • Un handshake complet 1-RTT, dans lequel le client peut envoyer des données d'application après un aller-retour et le serveur répond immédiatement après avoir reçu le premier message de handshake du client.

  • Un handshake 0-RTT, dans lequel le client utilise des informations qu'il a précédemment apprises sur le serveur pour envoyer immédiatement des données d'application. Ces données d'application peuvent être rejouées par un attaquant, donc 0-RTT ne convient pas pour transporter des instructions qui pourraient déclencher des actions dont la relecture pourrait avoir des conséquences indésirables.

La Figure 2 montre un handshake TLS simplifié avec des données d'application 0-RTT.

Client                                             Serveur

ClientHello
(données d'application 0-RTT)  -------->
                                                     ServerHello
                                            {EncryptedExtensions}
                                                       {Finished}
                                    <--------   [données d'application]
{Finished}                -------->

[données d'application]   <------->   [données d'application]

() Indique les messages protégés par les clés de données précoces (0-RTT)
{} Indique les messages protégés par les clés de handshake
[] Indique les messages protégés par les clés de données d'application (1-RTT)

Figure 2: Handshake TLS avec 0-RTT

La Figure 2 omet le message EndOfEarlyData, qui n'est pas utilisé dans QUIC ; voir la section 8.3. De même, QUIC n'utilise pas non plus les messages ChangeCipherSpec ou KeyUpdate. ChangeCipherSpec est redondant dans TLS 1.3 ; voir la section 8.4. QUIC dispose de son propre mécanisme de mise à jour de clé ; voir la section 6.

Les données sont protégées à l'aide de plusieurs niveaux de chiffrement :

  • Clés initiales (Initial keys)
  • Clés de données précoces (0-RTT) (Early data (0-RTT) keys)
  • Clés de handshake (Handshake keys)
  • Clés de données d'application (1-RTT) (Application data (1-RTT) keys)

Les données d'application ne peuvent apparaître qu'aux niveaux de données précoces et de données d'application. Les messages de handshake et d'alerte peuvent apparaître à n'importe quel niveau.

Un handshake 0-RTT peut être utilisé si le client et le serveur ont précédemment communiqué. Dans un handshake 1-RTT, le client ne peut pas envoyer de données d'application protégées tant qu'il n'a pas reçu tous les messages de handshake envoyés par le serveur.

Dernière mise à jour le