メインコンテンツまでスキップ

付録 A. RFC 4507 への変更に関する議論

RFC 4507 [RFC4507] は、クライアント側で維持される暗号化されたチケットを規定することにより、サーバー側の状態を維持せずに TLS セッションを再開する機構を定義しています。クライアントは、このチケットを SessionTicket hello 拡張でサーバーに提示します。RFC 4507 のエンコーディングは、TLS [RFC4346] で規定された XDR 形式のエンコーディングを使用していました。

エンコーディングのエラーにより、仕様は実際に展開されている実装と異なるものになっていました。これを執筆している時点で、RFC 4507 で規定されたエンコーディングに従っている既知の実装はありません。この RFC 4507 の更新は、文書を現在展開されている実装に合わせるものです。

RFC 4507 の誤ったエンコーディングは、2 つの長さフィールドをもたらしました。1 つは拡張の内容用で、もう 1 つはチケット自体用です。したがって、256 バイト長で先頭が 16 進値 FF FF であるチケットの場合、RFC 4507 によれば、拡張のエンコーディングは次のようになります。

     00 23          Ticket Extension type 35
     01 02          Length of extension contents
     01 00          Length of ticket
     FF FF .. ..    Actual ticket

本文書で提案された更新は、実装が実際にエンコードしている内容、すなわち冗長な長さフィールドを削除したものを反映しています。したがって、256 バイト長で先頭が 16 進値 FF FF であるチケットの場合、この更新によれば、拡張のエンコーディングは次のようになります。

     00 23          Extension type 35
     01 00          Length of extension contents (ticket)
     FF FF .. ..    Actual ticket

RFC 4507 に従って実装されたサーバーが、本文書に準拠したクライアントからチケット拡張を受け取ると、チケットの最初の 2 バイトをこのチケットの長さとして解釈します。これにより、長さフィールドの不整合が生じるか、または最初の 2 バイトが欠落したチケットの処理が行われることになります。最初の場合、サーバーは不正な長さに基づいて要求を拒否すべきです。2 番目の場合、サーバーは、不正なチケット、誤った鍵バージョン、または復号の失敗に基づいてチケットを拒否すべきです。この更新に基づくサーバー実装が RFC 4507 の拡張を受け取ると、最初の長さフィールドをチケットの長さとして解釈し、2 番目の長さの 2 バイトをチケットの最初のバイトとして含めるため、その結果、不正なチケット、誤った鍵バージョン、または復号の失敗に基づいてチケットが拒否されることになります。

RFC 4507 では、空の SessionTicket 拡張のエンコーディングが曖昧であったことに注意してください。RFC 4507 の実装は、それを次のようにエンコードした可能性があります。

     00 23      Extension type 35
     00 02      Length of extension contents
     00 00      Length of ticket

または、この更新と同じようにエンコードした可能性もあります。

     00 23      Extension type 35
     00 00      Length of extension contents

RFC 4507 のクライアントをサポートしたいサーバーは、受け取ったのと同じ方法でエンコードされた空の SessionTicket 拡張に応答すべきです。

サーバー実装は、有効な長さと区別できるクッキーをチケットの先頭に含めることによって、RFC 4507 の実装が存在する場合にそれを検出できるようにチケットを構築することができます。例えば、実装が 16 進値 FF FF で始まるようにチケットを構築した場合、チケットがどこから始まるかを判断し、存在する長さフィールドの種類から長さを正しく判断できます。

本文書は、以下に挙げるいくつかの追加の変更を RFC 4507 に対して行います。

  • 3.1 節において、サーバーが新しいチケットを発行せずにチケットを使用したセッション再開を許可できることの明確化。

  • 3.3 節において、有効期間がチケットを受け取った時点を基準とすることの明確化。

  • 3.3 節において、NewSessionTicket ハンドシェイクメッセージが Finished メッセージ用に生成されるハッシュに含まれることの明確化。

  • 3.4 節において、TLS セッション ID との相互作用の明確化。

  • 4 節において、チケットの完全性保護に SHA-256 の使用を推奨。

  • 4 節において、StatePlaintext 構造に追加データを含めることができることの明確化。