質問とスコープ
テレメトリクライアントにおいて、ターゲットサービスがリクエストとクライアントIDを紐付けられないようにしつつ、転送ノードがリクエスト内容を読み取れないようにしたいと考えています。鍵検出、HPKEカプセル化、エラー処理、リプレイ防御、リソースマッピング、レート制限、モニタリングを網羅して、OHTTPクライアント、リレー、ゲートウェイ、ターゲットを設計してください。
RFC 9458は暗号化されたHTTPメッセージの転送を標準化しています。リレーはクライアント接続を参照し、ゲートウェイは復号してターゲットを呼び出すため、どちらか単独でIDとコンテンツの両方を把握することはできません。OHTTPは匿名ネットワークではありません。メッセージ長、タイミング、リレーとゲートウェイの結託（collusion）、クライアントメタデータ、アプリケーション識別子は依然として個別に考慮する必要があります。
面接官がテストしていること
- Client、Relay、Gateway、Targetが閲覧できる情報と、信頼の境界がどこにあるかを定義できるか。
- ゲートウェイの公開鍵、HPKEリクエスト/レスポンスのカプセル化、およびメディアタイプについて説明できるか。
- リプレイ防御、リクエストサイズ制限、タイムアウト、エラーマッピングを設計できるか。
- 1対1のリレー/ゲートウェイリソースマッピング、トラフィック解析、結託リスクに対処できるか。
- 鍵ローテーション、キャッシング、リトライ、クライアントのクロックスキューを処理できるか。
- 受信許可、復号失敗、リプレイ拒否、レイテンシ、メッセージ長分布のメトリクスを用いて検証できるか。
最初に明確にすべき質問
- これは一方向のテレメトリ、パブリックな読み取り、それとも重要度の高い書き込みですか？機密性の高い書き込みには、より強力な認証とリプレイ制御が必要です。
- リレーとゲートウェイは異なる事業者によって運用されていますか、それとも単一の組織が両方を所有できますか？
- ターゲットはユーザー権限、テナント、またはリージョンによって異なる結果を返しますか？
- リクエストサイズ、バッチ処理ウィンドウ、レイテンシ、損失許容度の制限はどのようになっていますか？
- 鍵の有効期限切れ後にクライアントは設定を再検出できますか？また、どのログフィールドをマスキングする必要がありますか？
30秒での回答
私は4つの境界を設定します。クライアントはリレーに接続し、リレーはカプセル化されたメッセージのみを転送し、ゲートウェイはターゲットを呼び出す前にメッセージを復号します。クライアントはゲートウェイの鍵設定を検出し、HPKEを使用してバイナリHTTPをカプセル化します。レスポンスは逆方向にカプセル化されます。ゲートウェイは時間ウィンドウ、一意のリクエスト識別子、またはアプリケーションの冪等性を使用してリプレイを拒否し、リレーは接続リソースとメッセージリソースを制限します。オーバーラップを設けて鍵をローテーションし、復号失敗、リプレイ拒否、レイテンシ、メッセージ長分布を監視します。OHTTPを結託やトラフィック解析への完全な対策として提示すべきではありません。
ステップごとの詳細解説
1. 4つの責務を定義する
Clientはターゲットリソースとゲートウェイ公開鍵を認識します。Relayはクライアントのネットワーク接続を認識しますが、カプセル化されたコンテンツを読み取るべきではありません。Gatewayは復号して通常のHTTPをTargetに送信し、Targetはゲートウェイを送信元として認識します。単一の当事者がIDとコンテンツを容易に関連付けられないよう、デプロイ、ログ、アクセス権限を分離します。
2. 鍵設定の検出と検証
クライアントは、鍵識別子、HPKEアルゴリズム、公開鍵を含むゲートウェイ鍵設定を取得します。これには認証済みのソース、バージョン、有効期限が必要です。サポートされていないアルゴリズムや期限切れの鍵は拒否します。ローテーション中は、クライアントのキャッシュとリクエストウィンドウが経過するまで、新旧の鍵を併せて公開します。
3. リクエストとレスポンスのカプセル化
クライアントはバイナリHTTPリクエストをエンコードし、HPKEを用いて message/ohttp-req ペイロードとしてカプセル化します。ゲートウェイはカプセル化を解除し、メソッド、ターゲットリソース、サイズ、コンテンツタイプを検証します。その後、レスポンスを message/ohttp-res としてカプセル化します。リレーは内部のHTTPを解析したり、平文ステータスに基づいてルーティングしたりしてはなりません。
Client -- TLS --> Relay -- opaque OHTTP --> Gateway -- HTTP --> Target
Client <-- opaque response -- Relay <-- OHTTP response -- Gateway4. 認証、リプレイ、冪等性の処理
OHTTPはネットワークIDを隠蔽しますが、ビジネスユーザーを認証するわけではありません。書き込み処理には、アプリケーション署名、ワンタイムnonce、時間ウィンドウ、または冪等性キーを使用します。ゲートウェイは最小限のリプレイ検出状態を保持し、重複したカプセル化メッセージを拒否します。テレメトリバッチには冪等なイベントIDを持たせ、リトライによって二重カウントが発生しないようにします。
5. エラー処理とリソースマッピング
カプセル解除（decapsulation）に失敗した場合、ゲートウェイは秘密鍵の詳細を公開することなく、構造化された鍵エラーまたはカプセル化エラーを返します。ターゲットのビジネスエラーは、OHTTPレスポンスの内部に含まれて返送されます。メッセージが誤ったターゲットに到達しないよう、リレーからゲートウェイへのリソースマッピングは固定かつ検証可能である必要があります。各レイヤーでタイムアウト、サイズ、過負荷に対して個別の制限を適用します。
6. プライバシー漏洩とトラフィック解析の評価
暗号化を行っても、リレーがクライアントIP、タイミング、メッセージ長を把握することや、ゲートウェイがリクエスト頻度や復号されたアプリケーションフィールドを把握することを防ぐことはできません。パディング、バッチ処理、レート制限、ログの分離により、レイテンシとコストのトレードオフを伴いながら相関関係を低減できます。OHTTPがリレーとゲートウェイの結託を完全に防ぐと主張してはなりません。
7. カナリアリリース、監視、フォールバック
小規模なクライアントコホートと専用のリレー/ゲートウェイリソースから開始します。設定ヒット数、カプセル解除成功率、リプレイ拒否、ターゲットの5xx、p95レイテンシ、メッセージサイズバケット、フォールバック率を追跡します。インシデント発生時は、ターゲットまたはクライアントバージョンごとに局所的にOHTTPを無効化します。通常のHTTPSフォールバックにはプライバシーレビューが必要です。内部のIDフィールドではなく、設定ID、エラークラス、リクエストハッシュを記録します。
質の高い模範解答
クライアント、リレー、ゲートウェイ、ターゲットを4つの責任ドメインに分離します。クライアントはゲートウェイのHPKE鍵設定を取得・検証し、バイナリHTTPをカプセル化してリレーに送信します。リレーは不透明なバイト列を転送します。ゲートウェイはカプセル化を解除し、サイズとリソースマッピングを検証した上で、自身のIDを用いてターゲットを呼び出します。レスポンスは復路でカプセル化されます。
OHTTPはビジネス認証を提供せず、リレーとゲートウェイの結託を防ぐこともできません。したがって、書き込みにはアプリケーション署名、nonce、または冪等性キーが必要であり、ゲートウェイ側での時間ウィンドウによるリプレイチェックも伴います。重複ウィンドウを設けて鍵をローテーションし、リレーの接続数とメッセージリソースを制限します。カプセル解除失敗、リプレイ拒否、レイテンシ、サイズ分布、ビジネスエラーについてカナリア監視を実施し、明示的なプライバシーレビューを経た後にのみ通常のHTTPSフォールバックを許可します。
よくある間違い
- リレーを復号プロキシとして扱う → プライバシー境界が消失する → リレーには外部接続と不透明なメッセージの処理のみを担当させる。
- OHTTPがユーザーを認証すると想定する → ターゲットが正規のビジネス主体を識別できない → アプリケーション署名または認可トークンを追加する。
- メッセージ長とタイミングを無視する → トラフィック解析によってリクエストを関連付けられてしまう → レイテンシコストを測定しながらパディングとバッチ処理を使用する。
- 冪等性なしで書き込みをリトライする → テレメトリの二重カウントや副作用の重複が発生する → nonce、イベントID、リプレイウィンドウを使用する。
- リレーとゲートウェイで紐付け可能なログを共有する → 単一の当事者がIDとコンテンツを復元できてしまう → 運用者、記録フィールド、アクセス権限を分離する。
フォローアップの質問と回答
OHTTPはリレーとゲートウェイの結託を防げますか？
防げません。本プロトコルは限定された信頼と運用上の分離に依存しています。結託した当事者は接続IDと復号されたコンテンツを関連付けることができるため、組織、ログ、アクセス制御を独立して維持する必要があります。
ゲートウェイはどのようにリプレイを防ぎますか？
書き込みに対して時間ウィンドウ、nonce、冪等イベントID、またはアプリケーション署名を使用します。最小限の検出状態を保持し、重複したカプセル化メッセージを拒否します。接続ごとのTLSのみでは、接続を跨いだリプレイを防ぐことはできません。
なぜリソースマッピングが必要なのですか？
リレーはカプセル化されたリクエストを目的のゲートウェイ/ターゲットリソースに転送する必要があります。固定マッピングにより、鍵、ポリシー、レート制限、監査の境界が検証可能になり、互換性のないゲートウェイへの配信を防ぐことができます。
ゲートウェイの公開鍵はどのようにローテーションしますか？
キャッシュ、バッチ処理、リトライのウィンドウ期間中に古い鍵を保持しながら、バージョン管理された有効期限付きの新しい設定を公開します。鍵IDごとにヒット数とカプセル解除の失敗を監視し、その後に古い秘密鍵を廃止します。
OHTTPは重要度の高い書き込みに適していますか？
慎重に使用する場合に限られます。ネットワークIDは隠蔽されますが、認証、認可、冪等性、監査の代わりにはなりません。レイテンシとプライバシーのトレードオフを受け入れる前に、アプリケーションの主体とリプレイ境界を証明してください。
モニタリングでは何を記録すべきですか？
設定ID、リレー/ゲートウェイリソース、エラークラス、リクエストサイズバケット、リプレイ拒否、エンドツーエンドのレイテンシを記録します。内部ドメイン、ユーザー識別子、生のカプセル化コンテンツをデフォルトでログに記録してはなりません。