4. The DTLS Record Layer (La couche d'enregistrement DTLS)

4. The DTLS Record Layer

La couche d'enregistrement DTLS 1.3 est différente de la couche d'enregistrement TLS 1.3 et également différente de la couche d'enregistrement DTLS 1.2.

1. La structure DTLSCiphertext omit les champs de numéro de version et de type superflus.

2. DTLS ajoute un epoch et un numéro de séquence à l'en-tête d'enregistrement TLS. Ce numéro de séquence permet au destinataire de déchiffrer et vérifier correctement les enregistrements DTLS. Cependant, le nombre de bits utilisés pour les champs epoch et numéro de séquence dans la structure DTLSCiphertext a été réduit par rapport aux versions précédentes.

3. L'epoch DTLS sérialisé dans DTLSPlaintext fait 2 octets de long pour la compatibilité avec DTLS 1.2. Cependant, cette valeur est définie comme les 2 octets les moins significatifs de l'epoch de connexion, qui est un compteur de 8 octets incrémenté à chaque KeyUpdate. Voir la section 4.2 pour plus de détails. Le numéro de séquence est défini comme les 48 bits de poids faible du numéro de séquence de 64 bits. Les enregistrements en texte clair NE DOIVENT PAS être envoyés avec des numéros de séquence qui dépasseraient 2^48-1, donc les 16 bits supérieurs seront toujours 0.

4. La structure DTLSCiphertext a un en-tête de longueur variable.

Les enregistrements DTLSPlaintext sont utilisés pour envoyer des enregistrements non protégés et les enregistrements DTLSCiphertext sont utilisés pour envoyer des enregistrements protégés.

Les formats d'enregistrement DTLS sont présentés ci-dessous. Sauf indication explicite, la signification des champs est inchangée par rapport aux versions TLS/DTLS précédentes.

struct {
    ContentType type;
    ProtocolVersion legacy_record_version;
    uint16 epoch = 0
    uint48 sequence_number;
    uint16 length;
    opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;

struct {
     opaque content[DTLSPlaintext.length];
     ContentType type;
     uint8 zeros[length_of_padding];
} DTLSInnerPlaintext;

struct {
    opaque unified_hdr[variable];
    opaque encrypted_record[length];
} DTLSCiphertext;

Figure 2: Formats d'enregistrement DTLS 1.3

legacy_record_version: Cette valeur DOIT être définie sur {254, 253} pour tous les enregistrements autres que le ClientHello initial (c'est-à-dire, un qui n'est pas généré après un HelloRetryRequest), où elle peut également être {254, 255} à des fins de compatibilité. Elle DOIT être ignorée à toutes fins. Voir [TLS13], Annexe D.1 pour la justification.

epoch: Les 2 octets les moins significatifs de la valeur d'epoch de connexion.

unified_hdr: L'en-tête unifié (unified_hdr) est une structure de longueur variable, illustrée dans la figure 3.

encrypted_record: La forme chiffrée de la structure DTLSInnerPlaintext sérialisée.

  0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |0|0|1|C|S|L|E E|
  +-+-+-+-+-+-+-+-+
  | Connection ID |   Légende:
  | (if any,      |
  /  length as    /   C   - Connection ID (CID) present
  |  negotiated)  |   S   - Sequence number length
  +-+-+-+-+-+-+-+-+   L   - Length present
  |  8 or 16 bit  |   E   - Epoch
  |Sequence Number|
  +-+-+-+-+-+-+-+-+
  | 16 bit Length |
  | (if present)  |
  +-+-+-+-+-+-+-+-+

Figure 3: En-tête unifié DTLS 1.3

Fixed Bits: Les trois bits de poids fort du premier octet de l'en-tête unifié sont définis sur 001. Cela garantit que la valeur s'intégrera dans la région DTLS lors du multiplexage tel que décrit dans [RFC7983]. Cela garantit également qu'il est possible de distinguer les enregistrements DTLS 1.3 chiffrés des enregistrements DTLS 1.2 chiffrés lorsqu'ils sont transportés sur le même quartet hôte/port; un tel multiplexage n'est possible que lorsque les CID [RFC9146] sont utilisés, auquel cas les enregistrements DTLS 1.2 auront le type de contenu tls12_cid (25).

C: Le bit C (0x10) est défini si le Connection ID est présent.

S: Le bit S (0x08) indique la taille du numéro de séquence. 0 signifie un numéro de séquence de 8 bits, 1 signifie 16 bits. Les implémentations PEUVENT mélanger des numéros de séquence de différentes longueurs sur la même connexion.

L: Le bit L (0x04) est défini si la longueur est présente.

E: Les deux bits de poids faible (0x03) incluent les deux bits de poids faible de l'epoch.

Connection ID: CID de longueur variable. La fonctionnalité CID est décrite dans [RFC9146]. Un exemple peut être trouvé dans la section 9.1.

Sequence Number: Les 8 ou 16 bits de poids faible du numéro de séquence d'enregistrement. Cette valeur est de 16 bits si le bit S est défini sur 1, et de 8 bits si le bit S est 0.

Length: Identique au champ de longueur dans un enregistrement TLS 1.3.

Comme avec les versions précédentes de DTLS, plusieurs enregistrements DTLSPlaintext et DTLSCiphertext peuvent être inclus dans le même datagramme de transport sous-jacent.

La figure 4 illustre différents en-têtes d'enregistrement.

 0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
| Content Type  |     |0|0|1|1|1|1|E E|     |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|   16 bit      |     |               |     |8 bit Seq. No. |
|   Version     |     / Connection ID /     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+     |               |     |               |
|   16 bit      |     +-+-+-+-+-+-+-+-+     |   Encrypted   |
|    Epoch      |     |    16 bit     |     /   Record      /
+-+-+-+-+-+-+-+-+     |Sequence Number|     |               |
|               |     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|               |     |   16 bit      |
|   48 bit      |     |   Length      |       DTLSCiphertext
|Sequence Number|     +-+-+-+-+-+-+-+-+         Structure
|               |     |               |         (minimal)
|               |     |  Encrypted    |
+-+-+-+-+-+-+-+-+     /  Record       /
|    16 bit     |     |               |
|    Length     |     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|               |      DTLSCiphertext
|               |        Structure
/   Fragment    /          (full)
|               |
+-+-+-+-+-+-+-+-+

 DTLSPlaintext
   Structure

Figure 4: Exemples d'en-têtes DTLS 1.3

Le champ de longueur PEUT être omis en effaçant le bit L, ce qui signifie que l'enregistrement consomme tout le reste du datagramme dans le transport de niveau inférieur. Dans ce cas, il n'est pas possible d'avoir plusieurs enregistrements au format DTLSCiphertext sans champs de longueur dans le même datagramme. L'omission du champ de longueur DOIT uniquement être utilisée pour le dernier enregistrement dans un datagramme. Les implémentations PEUVENT mélanger des enregistrements avec et sans champs de longueur sur la même connexion.

Si un Connection ID est négocié, alors il DOIT être contenu dans tous les datagrammes. Les implémentations d'envoi NE DOIVENT PAS mélanger des enregistrements de plusieurs associations DTLS dans le même datagramme. Si le deuxième enregistrement ou un enregistrement ultérieur a un connection ID qui ne correspond pas à la même association utilisée pour les enregistrements précédents, le reste du datagramme DOIT être rejeté.

Une fois développés, l'epoch et le numéro de séquence peuvent être combinés dans une structure RecordNumber déballée, comme illustré ci-dessous:

struct {
    uint64 epoch;
    uint64 sequence_number;
} RecordNumber;

Cette valeur de 128 bits est utilisée dans le message ACK ainsi que dans l'entrée "record_sequence_number" de la fonction de chiffrement authentifié avec données associées (AEAD). La valeur d'en-tête entière illustrée dans la figure 4 (mais avant le chiffrement du numéro d'enregistrement; voir la section 4.2.3) est utilisée comme valeur de données supplémentaires pour la fonction AEAD. Par exemple, si la variante minimale est utilisée, les données associées (AD) font 2 octets de long. Notez que cette conception est différente du calcul des données supplémentaires pour DTLS 1.2 et pour DTLS 1.2 avec Connection IDs. Dans DTLS 1.3, le sequence_number de 64 bits est utilisé comme numéro de séquence pour le calcul AEAD; contrairement à DTLS 1.2, l'epoch n'est pas inclus.