4. The DTLS Record Layer (DTLSレコード層)

DTLS 1.3レコード層は, TLS 1.3レコード層とは異なり, DTLS 1.2レコード層とも異なります。

DTLSCiphertext構造体は, 余分なバージョン番号とタイプフィールドを省略します。
DTLSは, TLSレコードヘッダーにエポックとシーケンス番号を追加します。このシーケンス番号により, 受信者はDTLSレコードを正しく復号化および検証できます。ただし, DTLSCiphertext構造体のエポックおよびシーケンス番号フィールドに使用されるビット数は, 以前のバージョンから削減されています。
DTLSPlaintextでシリアライズされたDTLSエポックは, DTLS 1.2との互換性のために2オクテット長です。ただし, この値は接続エポックの最下位2オクテットとして設定され, 接続エポックはKeyUpdateごとに増分される8オクテットカウンターです。詳細は第4.2節を参照してください。シーケンス番号は, 64ビットシーケンス番号の下位48ビットに設定されます。プレーンテキストレコードは, 2^48-1を超えるシーケンス番号で送信してはなりません。したがって, 上位16ビットは常に0になります。
DTLSCiphertext構造体は, 可変長ヘッダーを持ちます。

DTLSPlaintextレコードは保護されていないレコードの送信に使用され, DTLSCiphertextレコードは保護されたレコードの送信に使用されます。

DTLSレコード形式を以下に示します。明示的に記載されていない限り, フィールドの意味は以前のTLS/DTLSバージョンから変更されていません。

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;

図2: DTLS 1.3レコード形式

legacy_record_version: 初期ClientHello(つまり, HelloRetryRequest後に生成されていないもの)以外のすべてのレコードについて, この値は{254, 253}に設定しなければなりません。互換性の目的で, 初期ClientHelloでは{254, 255}でもかまいません。すべての目的で無視しなければなりません。この根拠については, [TLS13]付録D.1を参照してください。

epoch: 接続エポック値の最下位2バイト。

unified_hdr: 統合ヘッダー(unified_hdr)は, 図3に示す可変長の構造体です。

encrypted_record: シリアライズされたDTLSInnerPlaintext構造体の暗号化形式。

  0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |0|0|1|C|S|L|E E|
  +-+-+-+-+-+-+-+-+
  | Connection ID |   凡例:
  | (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)  |
  +-+-+-+-+-+-+-+-+

図3: DTLS 1.3統合ヘッダー

Fixed Bits: 統合ヘッダーの最初のバイトの上位3ビットは001に設定されます。これにより, [RFC7983]で説明されているように多重化が実行される際に, 値がDTLS領域内に収まることが保証されます。また, 暗号化されたDTLS 1.3レコードと暗号化されたDTLS 1.2レコードが同じホスト/ポート4つ組で伝送される場合に, それらを区別できることも保証されます。このような多重化は, CID [RFC9146]が使用されている場合にのみ可能であり, その場合DTLS 1.2レコードはコンテンツタイプtls12_cid (25)を持ちます。

C: Connection IDが存在する場合, Cビット(0x10)が設定されます。

S: Sビット(0x08)は, シーケンス番号のサイズを示します。0は8ビットシーケンス番号を意味し, 1は16ビットを意味します。実装は, 同じ接続で異なる長さのシーケンス番号を混在させてもかまいません。

L: 長さが存在する場合, Lビット(0x04)が設定されます。

E: 下位2ビット(0x03)には, エポックの下位2ビットが含まれます。

Connection ID: 可変長CID。CID機能は[RFC9146]で説明されています。例は第9.1節にあります。

Sequence Number: レコードシーケンス番号の下位8ビットまたは16ビット。Sビットが1に設定されている場合, この値は16ビットであり, Sビットが0の場合は8ビットです。

Length: TLS 1.3レコードの長さフィールドと同一です。

以前のバージョンのDTLSと同様に, 複数のDTLSPlaintextおよびDTLSCiphertextレコードを同じ基礎となるトランスポートデータグラムに含めることができます。

図4は, さまざまなレコードヘッダーを示しています。

 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

図4: DTLS 1.3ヘッダー例

Lビットをクリアすることで長さフィールドを省略してもかまいません。これは, レコードが下位レベルトランスポートのデータグラムの残り全体を消費することを意味します。この場合, 同じデータグラム内に長さフィールドのない複数のDTLSCiphertext形式レコードを持つことはできません。長さフィールドの省略は, データグラムの最後のレコードにのみ使用しなければなりません。実装は, 同じ接続で長さフィールドのあるレコードとないレコードを混在させてもかまいません。

Connection IDがネゴシエートされた場合, すべてのデータグラムに含めなければなりません。送信実装は, 同じデータグラム内に複数のDTLSアソシエーションからのレコードを混在させてはなりません。2番目以降のレコードが以前のレコードに使用されたアソシエーションに対応しないconnection IDを持つ場合, データグラムの残りは破棄しなければなりません。

拡張すると, エポックとシーケンス番号は, 以下に示すように展開されたRecordNumber構造体に結合できます。

struct {
    uint64 epoch;
    uint64 sequence_number;
} RecordNumber;

この128ビット値は, ACKメッセージおよび関連データ付き認証暗号化(AEAD)関数への"record_sequence_number"入力で使用されます。図4に示されているヘッダー値全体(ただしレコード番号暗号化の前, 第4.2.3節参照)は, AEAD関数の追加データ値として使用されます。たとえば, 最小バリアントが使用される場合, 関連データ(AD)は2オクテット長です。この設計は, DTLS 1.2およびConnection ID付きDTLS 1.2の追加データ計算とは異なることに注意してください。DTLS 1.3では, 64ビットsequence_numberがAEAD計算のシーケンス番号として使用されます。DTLS 1.2とは異なり, エポックは含まれません。

4. The DTLS Record Layer (DTLSレコード層)​

4. The DTLS Record Layer (DTLSレコード層)