5. Extension Negotiation (Négociation de l'extension)

5.1. Extension Definition (Définition de l'extension)

Ce document définit une nouvelle extension TLS, extended_master_secret (avec le type d'extension 0x0017), qui est utilisée pour signaler au client et au serveur d'utiliser le calcul du secret maître étendu. Le champ extension_data de cette extension est vide. Ainsi, l'encodage entier de l'extension est 00 17 00 00 (en hexadécimal.)

Bien que ce document ne fasse référence qu'à TLS, l'extension proposée ici peut également être utilisée avec Datagram TLS (DTLS) [RFC6347].

Si le client et le serveur sont d'accord sur cette extension et qu'un handshake complet a lieu, le client et le serveur DOIVENT utiliser l'algorithme de dérivation du secret maître étendu, tel que défini dans la Section 4. Tous les autres calculs cryptographiques restent inchangés.

5.2. Client and Server Behavior: Full Handshake (Comportement du client et du serveur : Handshake complet)

Dans ce qui suit, nous utilisons l'expression "avorter le handshake" comme raccourci pour mettre fin au handshake en envoyant une alerte fatale handshake_failure.

Dans tous les handshakes, un client implémentant ce document DOIT envoyer l'extension extended_master_secret dans son ClientHello.

Si un serveur implémentant ce document reçoit l'extension extended_master_secret, il DOIT inclure l'extension dans son message ServerHello.

Si le ClientHello et le ServerHello contiennent tous deux l'extension, la nouvelle session utilise le calcul du secret maître étendu.

Si le serveur reçoit un ClientHello sans l'extension, il DEVRAIT avorter le handshake s'il ne souhaite pas interopérer avec les clients hérités. S'il choisit de continuer le handshake, alors il NE DOIT PAS inclure l'extension dans le ServerHello.

Si un client reçoit un ServerHello sans l'extension, il DEVRAIT avorter le handshake s'il ne souhaite pas interopérer avec les serveurs hérités.

Si le client et le serveur choisissent de continuer un handshake complet sans l'extension, ils DOIVENT utiliser la dérivation standard du secret maître pour la nouvelle session. Dans ce cas, la nouvelle session n'est pas protégée par les mécanismes décrits dans ce document. Ainsi, les implémenteurs devraient suivre les directives de la Section 5.4 pour éviter les scénarios d'utilisation dangereux. En particulier, le secret maître dérivé de la nouvelle session ne devrait pas être utilisé pour l'authentification au niveau de l'application.

5.3. Client and Server Behavior: Abbreviated Handshake (Comportement du client et du serveur : Handshake abrégé)

Le client NE DEVRAIT PAS proposer un handshake abrégé pour reprendre une session qui n'utilise pas un secret maître étendu. Au lieu de cela, il DEVRAIT proposer un handshake complet.

Si le client choisit de proposer un handshake abrégé même pour de telles sessions afin de prendre en charge la reprise non sécurisée héritée, alors la connexion actuelle n'est pas protégée par les mécanismes de ce document. Ainsi, le client devrait suivre les directives de la Section 5.4 pour éviter les scénarios d'utilisation dangereux. En particulier, la renégociation n'est plus sécurisée sur cette connexion, même si le client et le serveur prennent en charge l'extension d'indication de renégociation [RFC5746].

Lorsqu'il propose un handshake abrégé, le client DOIT envoyer l'extension extended_master_secret dans son ClientHello.

Si un serveur reçoit un ClientHello pour un handshake abrégé proposant de reprendre une session précédente connue, il se comporte comme suit :

Si la session d'origine n'utilisait pas l'extension extended_master_secret mais que le nouveau ClientHello contient l'extension, alors le serveur NE DOIT PAS effectuer le handshake abrégé. Au lieu de cela, il DEVRAIT continuer avec un handshake complet (comme décrit dans la Section 5.2) pour négocier une nouvelle session.
Si la session d'origine utilisait l'extension extended_master_secret mais que le nouveau ClientHello ne la contient pas, le serveur DOIT avorter le handshake abrégé.
Si ni la session d'origine ni le nouveau ClientHello n'utilisent l'extension, le serveur DEVRAIT avorter le handshake. S'il continue avec un handshake abrégé afin de prendre en charge la reprise non sécurisée héritée, la connexion n'est plus protégée par les mécanismes de ce document, et le serveur devrait suivre les directives de la Section 5.4.
Si le nouveau ClientHello contient l'extension et que le serveur choisit de continuer le handshake, alors le serveur DOIT inclure l'extension extended_master_secret dans son message ServerHello.

Si un client reçoit un ServerHello qui accepte un handshake abrégé, il se comporte comme suit :

Si la session d'origine n'utilisait pas l'extension extended_master_secret mais que le nouveau ServerHello contient l'extension, le client DOIT avorter le handshake.
Si la session d'origine utilisait l'extension mais que le nouveau ServerHello ne contient pas l'extension, le client DOIT avorter le handshake.

Si le client et le serveur continuent le handshake abrégé, ils dérivent les clés de connexion pour la nouvelle session comme d'habitude à partir du secret maître de la session d'origine.

5.4. Interoperability Considerations (Considérations relatives à l'interopérabilité)

Pour permettre l'interopérabilité avec les clients et serveurs hérités, un pair TLS peut décider d'accepter des handshakes complets qui utilisent le calcul du secret maître hérité. Si c'est le cas, ils doivent différencier les sessions qui utilisent des secrets maîtres hérités et étendus en ajoutant un drapeau à l'état de la session.

Si un client ou un serveur choisit de continuer avec un handshake complet sans l'extension de secret maître étendu, alors la nouvelle session devient vulnérable à l'attaque de synchronisation de clé de l'homme du milieu décrite dans la Section 1. Par conséquent, le client ou le serveur NE DOIT PAS exporter de matériel de clé basé sur le nouveau secret maître pour toute authentification ultérieure au niveau de l'application. En particulier, il DOIT désactiver [RFC5705] et tout protocole d'authentification extensible (EAP) reposant sur l'authentification composée [COMPOUND-AUTH].

Si un client ou un serveur choisit de continuer un handshake abrégé pour reprendre une session qui n'utilise pas le secret maître étendu, alors la connexion actuelle devient vulnérable à une attaque de synchronisation de journal de handshake de l'homme du milieu comme décrit dans la Section 1. Par conséquent, le client ou le serveur NE DOIT PAS utiliser le verify_data du handshake actuel pour l'authentification au niveau de l'application. En particulier, le client DOIT désactiver la renégociation et toute utilisation de la liaison de canal "tls-unique" [RFC5929] sur la connexion actuelle.

Si la session d'origine utilise un secret maître étendu mais que le ClientHello ou le ServerHello dans le handshake abrégé n'inclut pas l'extension, il PEUT être sûr de continuer le handshake abrégé car il est protégé par le secret maître étendu de la session d'origine. Ce scénario peut se produire, par exemple, lorsqu'un serveur qui implémente cette extension établit une session mais que la session est ensuite reprise sur un autre serveur qui ne prend pas en charge l'extension. Comme de telles situations sont inhabituelles et susceptibles d'être le résultat de mauvaises configurations transitoires ou involontaires, ce document recommande que le client et le serveur DOIVENT avorter de tels handshakes.