Annexe A. Discussion des modifications apportées à la RFC 4507

La RFC 4507 [RFC4507] définit un mécanisme permettant de reprendre une session TLS sans maintenir d'état côté serveur, en spécifiant un ticket chiffré qui est conservé sur le client. Le client présente ce ticket au serveur dans une extension hello SessionTicket. L'encodage de la RFC 4507 utilisait l'encodage de style XDR spécifié dans TLS [RFC4346].

Une erreur dans l'encodage faisait diverger la spécification des implémentations déployées. Au moment de la rédaction de ce document, aucune implémentation connue ne suit l'encodage spécifié dans la RFC 4507. Cette mise à jour de la RFC 4507 aligne le document sur ces implémentations actuellement déployées.

L'encodage erroné de la RFC 4507 aboutissait à deux champs de longueur : l'un pour le contenu de l'extension et l'autre pour le ticket lui-même. Ainsi, pour un ticket de 256 octets commençant par la valeur hexadécimale FF FF, l'encodage de l'extension serait le suivant selon la RFC 4507 :

     00 23          Ticket Extension type 35
     01 02          Length of extension contents
     01 00          Length of ticket
     FF FF .. ..    Actual ticket

La mise à jour proposée dans ce document reflète ce que les implémentations encodent réellement, à savoir qu'elle supprime le champ de longueur redondant. Ainsi, pour un ticket de 256 octets commençant par la valeur hexadécimale FF FF, l'encodage de l'extension serait le suivant selon cette mise à jour :

     00 23          Extension type 35
     01 00          Length of extension contents (ticket)
     FF FF .. ..    Actual ticket

Un serveur implémenté conformément à la RFC 4507 qui reçoit une extension de ticket provenant d'un client conforme à ce document interpréterait les deux premiers octets du ticket comme la longueur de ce ticket. Cela se traduira soit par un champ de longueur incohérent, soit par le traitement d'un ticket auquel manquent les deux premiers octets. Dans le premier cas, le serveur devrait rejeter la requête en raison d'une longueur malformée. Dans le second cas, le serveur devrait rejeter le ticket en raison d'un ticket malformé, d'une version de clé incorrecte ou d'un échec de déchiffrement. Une implémentation de serveur basée sur cette mise à jour qui reçoit une extension RFC 4507 interpréterait le premier champ de longueur comme la longueur du ticket et inclurait les deux octets de longueur suivants comme premiers octets du ticket, ce qui ferait rejeter le ticket en raison d'un ticket malformé, d'une version de clé incorrecte ou d'un échec de déchiffrement.

Notez que l'encodage d'une extension SessionTicket vide était ambigu dans la RFC 4507. Une implémentation de la RFC 4507 peut l'avoir encodée comme suit :

     00 23      Extension type 35
     00 02      Length of extension contents
     00 00      Length of ticket

ou elle peut l'avoir encodée de la même manière que cette mise à jour :

     00 23      Extension type 35
     00 00      Length of extension contents

Un serveur souhaitant prendre en charge les clients RFC 4507 devrait répondre à une extension SessionTicket vide encodée de la même manière qu'il l'a reçue.

Une implémentation de serveur peut construire les tickets de manière à pouvoir détecter une implémentation de la RFC 4507, si elle existait, en incluant au début des tickets un cookie qui peut être différencié d'une longueur valide. Par exemple, si une implémentation construisait des tickets commençant par les valeurs hexadécimales FF FF, elle pourrait alors déterminer où commence le ticket et déterminer correctement la longueur à partir du type de champs de longueur présents.

Ce document apporte quelques modifications supplémentaires à la RFC 4507, énumérées ci-dessous.

• Clarification du fait que le serveur peut autoriser la reprise de session à l'aide d'un ticket sans émettre de nouveau ticket, à la section 3.1.

• Clarification du fait que la durée de vie est relative au moment de la réception du ticket, à la section 3.3.

• Clarification du fait que le message de handshake NewSessionTicket est inclus dans le hachage généré pour les messages Finished, à la section 3.3.

• Clarification de l'interaction avec le TLS Session ID, à la section 3.4.

• Recommandation de l'utilisation de SHA-256 pour la protection de l'intégrité du ticket, à la section 4.

• Clarification du fait que des données supplémentaires peuvent être incluses dans la structure StatePlaintext, à la section 4.