要約

  • 第 03 版は作業中の Internet-Draft であり、RFC、実装、相互接続性、展開実績の証拠ではない。
  • 各端点は受信できる内部平文の最大値を方向別に広告する。この値はメモリー予約でも送信サイズの指示でもない。
  • レコードが大きくなると AEAD の利用量評価も変わるため、従来の件数ベースの鍵更新基準をそのまま流用できない。
  • TLS の超過は致命的終了、DTLS は通常の破棄という異なる失敗面を持ち、アプリケーション完了も別の証拠である。

暗号は件数だけを見ていない

TLS 1.3 と DTLS 1.3 の内部平文は通常 2^14 + 1 オクテットまでである。large_record_size_limit 草案は、64 から 2^30 - 256 までの受信上限を端点が示せる仕組みを提案する。大きな単位にまとめれば、繰り返すヘッダーや保護処理の比率を下げられる可能性がある。

しかし AEAD の安全限界は「何レコードか」という一つの数字では決まらない。方式、呼び出し回数、処理するデータ量が関係し、AES-GCM ではブロック数が重要になる。草案も従来サイズを超える場合に LargeRecordSizeLimit / 2^14 に関係する調整や、必要に応じたブロック計算を求めている。

したがって、上限変更は鍵運用の変更でもある。暗号スイート、方向、鍵 epoch、認証済みバイトまたは承認済みの保守的なブロック見積もり、レコード数、KeyUpdate の実施を同じ台帳に載せなければならない。握手成功はその台帳の正しさを証明しない。

広告値は受信側の発言である

この拡張は一つの共通最大値を選ばない。クライアントはサーバーから受け取れる最大値を示し、サーバーはクライアントから受け取れる最大値を示す。二つの値は異なってよい。

端点は、自分が受信用に広告した値より大きなレコードを送れる場合がある。送信時に従うべきなのは、相手が広告した受信上限だからである。方向を消して一つの「TLS 上限」にまとめる監視は、正常な送信を違反にし、実際の違反を別方向の大きな値で覆い隠す。

必要なのは、接続、役割、方向、ローカル方針、送信した広告、受信した広告、実際の内部平文長である。方向は表示上の補足ではなく、誰が何を受け取ると述べたかを確定する主語である。

最大値は目標値ではない

受信側が示すのは許可の天井であって、相手にそのサイズまで詰めるよう命じる値ではない。送信側は遅延、バッチ、輻輳、メモリー、アプリケーションのフラッシュ方針に応じて小さなレコードを選べる。

ヘッダー比率だけを最適化すると、対話的なデータまで大きな単位に待たせることがある。バルク転送では効率が上がっても、制御メッセージでは最初の認証済みデータが届く時刻を遅らせるかもしれない。同じ拡張を使っても、ワークロード別の送信方針は同じである必要がない。

64 未満または 2^30 - 256 を超える広告値は致命的 illegal_parameter の対象になる。この結果は広告が不正だったことを示すだけで、実装が近い値に丸めて続行する権限を与えない。

予約される資源はどこにも書かれていない

大きな値を広告しても、各接続に同じ容量の連続バッファを確保したことにはならない。実装はプール、ストリーム処理、全体制限、バックプレッシャーを用いることができる。一方、単一接続で最大レコードを受け取れたとしても、多数の遅い送信者が未完成状態を保持する負荷には耐えないかもしれない。

容量試験では、暗号文、AEAD 状態、保持された平文、padding、上位層の再構成、キャンセル、キュー滞在時間を数える必要がある。攻撃者が制御し得る並行性、つまり多くのレコードを開始して完了を遅らせる条件も欠かせない。

草案の最大値は構文上の境界であり、本番推奨値ではない。サービスごとの上限は、アロケータ、スケジューラ、過負荷時の動作と実測に基づいて決める。

padding も権限を消費する

TLS 1.3 の内部平文にはコンテンツ種別と padding が含まれ得る。アプリケーション内容だけなら上限内でも、padding を足して上限を越えれば超過である。プライバシー方針が追加するバイトも、プロトコルとメモリーにとって実在する。

ログは内容や秘密を保存せず、内部平文長、暗号文長、padding 方針の版、方向を残すべきである。アプリケーションバイト、保護されるバイト、ネットワーク上のバイトを一つの値にすると、どの制御が失敗したか分からない。

さらに、大きな TLS レコードは複数の TCP セグメントやパケットに分かれ得る。レコード数が減っても、パケット数、損失、再送、輻輳が同じ割合で減る保証はない。

TLS と DTLS は超過を同じように扱わない

TLS で許容値を超えるレコードを受信した場合、草案は致命的 record_overflow を求める。順序付きストリームの接続は終了する。長寿命セッションでは、方針の食い違いが直接の可用性問題になる。

DTLS では超過データグラムを破棄し、致命的アラートを送るべきではないとされる。データグラムの損失はモデルに含まれ、未認証の入力に破壊的な応答を返すとサービス拒否の道具になり得る。

監視はプロトコル、epoch、方向、観測長、適用上限、実施した動作、アラートを区別する必要がある。DTLS でアラートがないことを障害とみなす共通ルールは、正しい実装を誤検知する。

レコードの完了はアプリケーションの完了ではない

草案は、特に大きな DTLS メッセージで上位層の断片化を避けられる可能性を述べる。しかし一つのアプリケーションメッセージが必ず一つのレコードに収まるとは述べない。

メッセージは複数レコードにまたがり、レコード内のデータが上位層で複数の単位になることもある。受信、認証、再構成、解析、認可、業務結果は別々の段階である。「大容量拡張を交渉した接続数」を配信成功の分母にすると、使われなかった許可まで成果に含めてしまう。

実際に大きなレコードを送った接続、そのうち認証できたレコード、完成したメッセージ、受理された処理を段階別に数えるべきである。各段階の失敗原因も前段の無効を意味しない。

待ち時間は別に計測する

受信側は一般に、レコード全体の認証が成功するまで平文を信頼できるアプリケーション入力として渡せない。単位が大きいほど、先頭到着から認証完了までの時間が伸びる可能性がある。損失時には再送やキュー占有も重くなる。

ヘッダー削減は実在する動機だが、低遅延の証明ではない。サイズ分布、認証完了時間、キュー滞在、接続あたり保持量、同時未完成レコード、アプリケーションの完了時間を測る必要がある。平均だけでなく尾部も確認する。

効率と応答性の選択は、プロトコル上限ではなくサービス方針で行う。大きな単位を許可しつつ、実際の送信を小さく保つことも正当な設計である。

段階導入には戻る道が必要である

導入は構文上限より十分小さい値から始め、ワークロードと端点種別ごとに上げる。非対称値、遅い送信者、多数の部分レコード、最大 padding、損失、アプリケーションメッセージの大小を試験する。TLS と DTLS は別の失敗面として扱う。

上限を下げる回退は、新しい接続の広告を変えるだけで、既存接続の状態を自動で書き換えない。接続ドレイン、互換経路、鍵方針、相手の未対応とローカル無効化の識別が必要になる。

最終的な判断資料は、設定、方向別広告、実際のサイズ、認証、資源、鍵予算、再構成、アプリケーション結果を別々に示す。大きな封筒を許す決定と、その封筒を安全に使えたという結論を分離するためである。

情報源と限界

凍結資料は第 03 版と公式記録、履歴、参照、TLS ワーキンググループ、TLS 1.3 と改訂草案、DTLS 1.3、既存のレコードサイズ拡張、DTLS/SCTP、MLS、QUIC、AEAD 要件、AES-GCM スイート、IANA TLS 登録簿から成る。

これらはプロトコルと登録簿の本文を確立するだけで、出荷済み実装、採用、相互接続、性能向上、メモリー削減、遅延改善、障害、攻撃、アプリケーション結果を確立しない。冒頭は暗号台帳のずれを考えるための構成例である。

出典