DTLS 1.3 仕様は、本 2022 年 4 月に RFC 9147 として公開されました。DTLS プロトコルのセキュリティと効率を高めるために、多くの改善と追加が行われています。 wolfSSL では、新しい仕様をいち早く採用したいと考えているため、DTLS 1.3 の初期サポートを6 月に統合し、wolfSSL リリース 5.4.0 に登場させました。 このブログ投稿では、RFC 9147 のセクション 12 および 13 で説明されている DTLS 1.2 からの変更点のリストを確認し、それらがセキュリティに与える影響について詳しく説明します。
DTLS 1.3 のもう 1 つの注目に値する機能は、ポスト量子暗号です。 TLS 1.3 と同じインターフェースを使用して wolfSSL で利用できます。 詳細については、このブログ投稿を参照してください。
メッセージ交換を短縮する新しいハンドシェークパターン
TLS 1.3 では、ハンドシェークプロトコルが以前の 2 往復から 1往復に簡素化されました。 とはいえ、DTLS 1.2 と 1.3 は両方とも、ステートレス Cookie 交換を行う場合にはさらに1往復が必要となります。
以前のDTLS1.2のハンドシェーク
Client Server
------ ------
ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2
ClientHello --------> Flight 3
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
図１．DTLS1.2のハンドシェーク
最新のDTLS1.3のハンドシェーク
Client Server
------ ------
+--------+
ClientHello | Flight |
--------> +--------+
+--------+
<-------- HelloRetryRequest | Flight |
+ cookie +--------+
+--------+
ClientHello | Flight |
+ cookie --------> +--------+
ServerHello
{EncryptedExtensions} +--------+
{CertificateRequest*} | Flight |
{Certificate*} +--------+
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*} +--------+
{CertificateVerify*} | Flight |
{Finished} --------> +--------+
[Application Data]
+--------+
<-------- [ACK] | Flight |
[Application Data*] +--------+図２．DTLS1.3のハンドシェーク
暗号化と認証処理を簡略化
AEAD暗号は、統一された暗号化と認証操作を提供します。 (D)TLS 1.3 より前は、MAC-then-Encrypt と呼ばれる手法を使用して認証が行われていました。 これは、HMAC を使用してデータの認証済みコードを計算し、平文とコードの連結を暗号化します。 受信者は、HMAC コードを計算し、受信したものと比較することで、データの信頼性を確認できます。 AEAD 暗号は、これを 1 つの操作に単純化します。
HelloRetryRequestがHelloVerifyRequestの代わりに
HelloRetryRequest は、DTLS 1.2のHelloVerifyRequest を置き換えます。 これにより、ピアはセキュリティパラメータをネゴシエートし、同時に Cookie 交換を実行できます。
より柔軟な暗号化スイートのネゴシエーション
暗号スイートのネゴシエートは、複数の拡張機能に分離されました。 (D)TLS の以前のバージョンでは、対称および非対称暗号のすべての可能な順列が暗号スイート リストに含まれていました。 (D)TLS 1.3 では、暗号スイートには、接続に使用される AEAD およびハッシュ アルゴリズムのみが含まれます。 その他のセキュリティ パラメータは、supported_groups、signature_algorithms、key_share、pre_shared_key などの拡張機能でネゴシエートされます。
新たなセッション再開メカニズムと事前共有鍵認証の再定義
(D)TLS 1.3 では、セッションの再開と PSK が 1 つのメカニズムに統合されました。 セッションを再開するために、サーバーは、後続の接続で使用できるチケットを含む NewSessionTicket メッセージをクライアントに送信します。 「セッション ID」と(D)TLS 1.2までの 「セッション チケット」は廃止されました。 さらに、セッションを再開するとき、クライアントはハンドシェイクの最初のフライトですぐに「初期データ」を送信できます。 これは、ピアが最初のラウンドトリップでデータを交換できるようにするため、0-RTT データとも呼ばれます。 これは、新しい接続の遅延を大幅に削減し、ピア間の最初の通信ラウンドを高速化するのに役立ちます。
新たな鍵派生階層
TLS 1.3 では、HMACベースの拡張および鍵導出関数を使用してシークレットを導出する、新しいキー スケジュールを導入しました。 これにより、TLS 接続で使用される複数のシークレットが分離されます。 詳細については、このセクションを参照してください。
改良されたバージョンネゴシエーション
バージョン ネゴシエーションは、レコード ヘッダーにある値を使用しなくなりました。 サポートされているすべての (D)TLS バージョンを提示するために、拡張機能が使用されるようになりました。 この新しいメカニズムは、新しい (D)TLS バージョン値が提示されたときに失敗する一部のミドルボックスを克服するためのものです。
最適化されたレコード層のエンコーディング
DTLS 1.3 では、非常に効率的な「統合ヘッダー」が導入されています。 この新しいヘッダー形式は、エポック番号とシーケンス番号も難読化して、トラフィック分析を困難にします。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID | Legend:
| (if any, |
/ length as / C - コネクション ID (CID)
| negotiated) | S - シーケンス番号の長さ
+-+-+-+-+-+-+-+-+ L - 長さ
| 8 or 16 bit | E - エポック
|Sequence Number|
+-+-+-+-+-+-+-+-+
| 16 bit Length |
| (if present) |
+-+-+-+-+-+-+-+-+図３．ユニファイド・ヘッダー
CID機能の追加
RFC 9146 は、DTLS 1.2 に接続識別子を導入しました。 同様のメカニズムが DTLS 1.3 で定義されています。 CID のユーザーは、IP 4 タプルの代わりに CID に従って多重化されるようにパケットをマークして、一度に複数のパスを介してレコードを送信できるようにすることができます。
過去のDTLS関係の記事：