4.2. Sequence Number and Epoch (Numéro de séquence et epoch)

4.2. Sequence Number and Epoch

DTLS utilise un numéro de séquence explicite ou partiellement explicite, plutôt qu'implicite, porté dans le champ sequence_number de l'enregistrement. Les numéros de séquence sont maintenus séparément pour chaque epoch, chaque sequence_number étant initialement 0 pour chaque epoch.

Le numéro d'epoch est initialement zéro et est incrémenté chaque fois que le matériel de clé change et qu'un expéditeur vise à rechiffrer. Plus de détails sont fournis dans la section 6.1.

4.2.1. Processing Guidelines (Directives de traitement)

Étant donné que les enregistrements DTLS peuvent être réordonnés, un enregistrement de l'epoch M peut être reçu après que l'epoch N (où N > M) ait commencé. Les implémentations DEVRAIENT rejeter les enregistrements des epochs antérieurs mais PEUVENT choisir de conserver le matériel de clé des epochs précédents jusqu'au MSL par défaut spécifié pour TCP [RFC0793] pour permettre le réordonnancement des paquets. (Notez que l'intention ici est que les implémenteurs utilisent les directives actuelles de l'IETF pour le MSL, comme spécifié dans [RFC0793] ou ses successeurs, et non qu'ils tentent d'interroger le MSL que la pile TCP du système utilise.)

Inversement, il est possible que des enregistrements protégés avec le nouvel epoch soient reçus avant la fin d'une poignée de main. Par exemple, le serveur peut envoyer son message Finished puis commencer à transmettre des données. Les implémentations PEUVENT soit mettre en mémoire tampon soit rejeter de tels enregistrements, bien que lorsque DTLS est utilisé sur des transports fiables (par exemple, SCTP [RFC4960]), ils DEVRAIENT être mis en mémoire tampon et traités une fois la poignée de main terminée. Notez que les restrictions de TLS sur le moment où les enregistrements peuvent être envoyés s'appliquent toujours, et le récepteur traite les enregistrements comme s'ils avaient été envoyés dans le bon ordre.

Les implémentations DOIVENT envoyer des retransmissions de messages perdus en utilisant le même epoch et le même matériel de clé que la transmission d'origine.

Les implémentations DOIVENT soit abandonner une association soit rechiffrer avant de permettre au numéro de séquence de boucler.

Les implémentations NE DOIVENT PAS permettre à l'epoch de boucler, mais DOIVENT à la place établir une nouvelle association, terminant l'ancienne association.

4.2.2. Reconstructing the Sequence Number and Epoch (Reconstruction du numéro de séquence et de l'epoch)

Lors de la réception d'enregistrements DTLS protégés, le destinataire n'a pas de valeur d'epoch ou de numéro de séquence complète dans l'enregistrement et il y a donc une certaine possibilité d'ambiguïté. Étant donné que le numéro de séquence complet est utilisé pour calculer le nonce par enregistrement et que l'epoch détermine les clés, l'échec de la reconstruction de ces valeurs conduit à l'échec de la déprotection de l'enregistrement, et donc les implémentations PEUVENT utiliser un mécanisme de leur choix pour déterminer les valeurs complètes. Cette section fournit un algorithme qui est comparativement simple et que les implémentations sont RECOMMANDÉES de suivre.

Si les bits d'epoch correspondent à ceux de l'epoch actuel, alors les implémentations DEVRAIENT reconstruire le numéro de séquence en calculant le numéro de séquence complet qui est numériquement le plus proche de un plus le numéro de séquence de l'enregistrement le plus élevé déprotégé avec succès dans l'epoch actuel.

Pendant la phase de poignée de main, les bits d'epoch indiquent sans ambiguïté la clé correcte à utiliser. Après la fin de la poignée de main, si les bits d'epoch ne correspondent pas à ceux de l'epoch actuel, les implémentations DEVRAIENT utiliser l'epoch passé le plus récent qui a des bits correspondants, puis reconstruire le numéro de séquence pour cet epoch comme décrit ci-dessus.

4.2.3. Record Number Encryption (Chiffrement du numéro d'enregistrement)

Dans DTLS 1.3, lorsque les enregistrements sont chiffrés, les numéros de séquence des enregistrements sont également chiffrés. Le modèle de base est que l'algorithme de chiffrement sous-jacent utilisé avec l'algorithme AEAD est utilisé pour générer un masque qui est ensuite XORé avec le numéro de séquence.

Lorsque l'AEAD est basé sur AES, alors le masque est généré en calculant AES-ECB sur les 16 premiers octets du texte chiffré:

Mask = AES-ECB(sn_key, Ciphertext[0..15])

Lorsque l'AEAD est basé sur ChaCha20, alors le masque est généré en traitant les 4 premiers octets du texte chiffré comme le compteur de bloc et les 12 octets suivants comme le nonce, en les passant à la fonction de bloc ChaCha20 (Section 2.3 de [CHACHA]):

Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])

Le sn_key est calculé comme suit:

[sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)

[sender] désigne le côté émetteur. La valeur Secret par epoch à utiliser est décrite dans la section 7.3 de [TLS13]. Notez qu'une nouvelle clé est utilisée pour chaque epoch: parce que l'epoch est envoyé en clair, cela n'entraîne pas d'ambiguïté.

Le numéro de séquence chiffré est calculé en XORant les octets de tête du masque avec la représentation sur le fil du numéro de séquence. Le déchiffrement est accompli par le même processus.

Cette procédure nécessite que la longueur du texte chiffré soit d'au moins 16 octets. Les récepteurs DOIVENT rejeter les enregistrements plus courts comme s'ils avaient échoué à la déprotection, comme décrit dans la section 4.5.2. Les expéditeurs DOIVENT remplir les textes en clair courts (en utilisant le mécanisme de remplissage d'enregistrement conventionnel) afin de créer un texte chiffré de longueur appropriée. Notez que la plupart des algorithmes AEAD DTLS ont une étiquette d'authentification de 16 octets et n'ont pas besoin de remplissage. Cependant, certains algorithmes, tels que TLS_AES_128_CCM_8_SHA256, ont une étiquette d'authentification plus courte et peuvent nécessiter un remplissage pour les entrées courtes.

Les suites de chiffrement futures, qui ne sont pas basées sur AES ou ChaCha20, DOIVENT définir leur propre chiffrement de numéro de séquence d'enregistrement afin d'être utilisées avec DTLS.

Notez que le chiffrement du numéro de séquence n'est appliqué qu'à la structure DTLSCiphertext et non à la structure DTLSPlaintext, même si elle contient également un numéro de séquence.