6. セキュリティに関する考慮事項
6.1. HTTP メッセージは完全には保護されない
この文書は、HTTP 表現データまたはコンテンツを特定の種類の破損から保護するデータ整合性メカニズムを指定していますが、HTTP ヘッダーおよびトレーラーフィールドは保護しません。
整合性フィールドは、HTTP メッセージの悪意のある改ざんに対する一般的な保護を意図したものではありません。追加のセキュリティメカニズムがない場合、パス上の悪意のあるアクターは、ダイジェスト値を完全に削除するか、操作された表現データまたはコンテンツに対して計算された新しいダイジェスト値に置き換えることができます。この攻撃は、この文書で説明されているメカニズムと、Transport Layer Security (TLS) やデジタル署名（たとえば、HTTP メッセージ署名 [SIGNATURES]）などの他のアプローチを組み合わせることで軽減できます。
6.2. エンドツーエンドの整合性
整合性フィールドは、実装エラー、望ましくない「変換プロキシ」（[HTTP] のセクション 7.7 を参照）、またはデータが複数のホップやシステム境界を通過する際のアクションによる表現データまたはコンテンツの変更を検出するのに役立ちます。エンドツーエンドの表現データ整合性のための単純なメカニズムであっても、ユーザーエージェントが HTML パーサー、ビデオプレーヤーなどに解析を渡す前にリソースの取得が成功したことを検証できるため、価値があります。
メタデータはどの段階でも操作される可能性があるため、これらのメカニズムを単独で使用しても、複数のホップにわたる HTTP メッセージのエンドツーエンドの整合性は提供されないことに注意してください。メタデータを保護する方法については、セクション 6.3 で説明します。
6.3. 署名での使用
デジタル署名は、メッセージの送信元の確実な識別を提供するために、チェックサムとともに広く使用されています [FIPS186-5]。このような署名は 1 つ以上の HTTP フィールドを保護でき、整合性フィールドがこのセットに含まれる場合は追加の考慮事項があります。
整合性フィールドで使用できるデジタル署名のタイプまたは形式に制限はありません。考えられるアプローチの 1 つは、それらを HTTP メッセージ署名 [SIGNATURES] と組み合わせることです。
ダイジェストは、「表現メタデータ」（たとえば、Content-Type、Content-Encoding などの値）に明示的に依存します。整合性フィールドを保護するが他の「表現メタデータ」を保護しない署名は、通信を改ざんにさらす可能性があります。たとえば、アクターが Content-Type フィールド値を操作して、受信者でダイジェスト検証の失敗を引き起こし、アプリケーションが表現にアクセスできないようにする可能性があります。このような攻撃は、両方のエンドポイントのリソースを消費します。セクション 3.2 も参照してください。
整合性フィールドを適用する場合、署名は敵対的な設定と見なされる可能性があります（セクション 5 を参照）。Repr-Digest は、署名と組み合わせると興味深い可能性を提供します。送信するコンテンツがないシナリオでは、空の文字列のダイジェストをメッセージに含めることができ、署名されている場合、受信者は事故または意図的な操作の結果としてコンテンツが追加されたかどうかを検出するのに役立ちます。逆のシナリオもサポートされています。コンテンツの整合性フィールドを含めて署名することで、受信者はコンテンツが削除された場所を検出するのに役立ちます。
整合性フィールドの破壊は、署名の検証に影響を与える可能性があります。このような破壊の例には、ダイジェストの重複排除や、異なるフィールド値の結合が含まれます（[HTTP] のセクション 5.2 を参照）。
6.4. トレーラーフィールドでの使用
トレーラーセクションで整合性フィールドを送信する前に、送信者は、仲介者がトレーラーをドロップすることが明示的に許可されていることを考慮する必要があります（[HTTP] のセクション 6.5.2 を参照）。
整合性フィールドがトレーラーセクションで使用される場合、フィールド値はコンテンツの後に受信されます。トレーラーセクションの前にコンテンツを先行処理すると、ダイジェストの検証が妨げられ、無効なデータの処理につながる可能性があります。
トレーラーセクションで整合性フィールドを使用する利点の 1 つは、バイトが送信されるときにハッシュ化できることです。ただし、これらの利点を無効にするような方法でコンテンツの処理を必要とするハッシュアルゴリズムを設計することは可能です。たとえば、Merkle Integrity Content Encoding [MICE] では、コンテンツを逆順で処理する必要があります。これは、完全なデータが利用可能である必要があることを意味し、ヘッダーセクションとトレーラーセクションで整合性フィールドを送信する場合の処理の違いはごくわずかであることを意味します。
6.5. Content-Encoding 内のバリエーション
コンテンツコーディングメカニズムは、異なるエンコーディングパラメータをサポートできます。つまり、同じ入力コンテンツが異なる出力を生成する可能性があります。たとえば、GZIP は複数の圧縮レベルをサポートしています。このようなエンコーディングパラメータは通常、表現メタデータとして通信されません。たとえば、異なる圧縮レベルはすべて同じ「Content-Encoding: gzip」フィールドを使用します。他の例としては、[RFC8188] で定義されている aes128gcm コンテンツコーディングなど、エンコーディングがナンスやタイムスタンプに依存する場合が含まれます。
コンテンツコーディング内にバリエーションが存在する可能性があるため、コンテンツ全体が永続化されない限り、整合性フィールドによって伝達されるチェックサムを使用して「保存時」の整合性の証明を提供することはできません。
6.6. アルゴリズムのアジリティ
ハッシュアルゴリズムのセキュリティプロパティは固定されていません。アルゴリズムのアジリティ（[RFC7696] を参照）は、IANA HTTP ダイジェストフィールドのハッシュアルゴリズムレジストリからハッシュアルゴリズムを選択する柔軟性を実装に提供することで実現されます（セクション 7.2 を参照）。
弱いアルゴリズムからの移行は、Want-Content-Digest または Want-Repr-Digest を使用したハッシュアルゴリズムのネゴシエーション（セクション 4 を参照）、または受信者が選択する複数のダイジェストを送信することによってサポートされます。セキュリティのためにダイジェストに依存する受信者は、受け入れてもよい最も弱いアルゴリズムに対する攻撃に対して脆弱になります。エンドポイントは、複数の値を送信するとリソースが消費され、受信者がそれらを無視すると無駄になる可能性があることに注意してください（セクション 3 を参照）。
アルゴリズムのアジリティにより、より強力なアルゴリズムへの移行が可能になりますが、弱いアルゴリズムの使用を防ぐことはできません。整合性フィールドは、ハッシュアルゴリズムのダウングレードまたは置換攻撃（[RFC6211] のセクション 1 を参照）に対する軽減策を提供しません。このような攻撃から保護するために、エンドポイントはサポートされているアルゴリズムのセットをより強力なものに制限し、TLS やデジタル署名を使用してフィールドの値を保護できます。
6.7. リソースの枯渇
整合性フィールドの検証は、計算リソースを消費します。リソースの枯渇を回避するために、実装では、アルゴリズムタイプの検証、検証の数、またはコンテンツのサイズを制限できます。これらの場合、検証を完全にスキップしたり、より優先度の高いアルゴリズムの検証失敗を無視したりすると、ダウングレード攻撃の可能性が残ります（セクション 6.6 を参照）。