RFC 7541 Quiz

**Explanation:** RFC 7541 Sections 2.3と2.4で, HPACKはindexed representationとliteral representationを使ってheader listをencodeします. static tableは仕様で固定され, dynamic tableはconnection上で同期されます. 既存entryを参照することでrepeated header byteを減らすことが目的です. HPACKはcompression formatであり, confidentialityやserver authenticationを提供しません. それらはtransport securityとpeer-validation policyの別の責務です.

**Explanation:** RFC 7541 Section 2.3.2のdynamic tableは、header blockを処理する間にentryが追加またはevictされるconnection固有のstateです。各方向には独立したdynamic tableがあります。ある方向のencoder stateと、peer decoderの対応するstateがずれれば、indexed referenceを正しく復元できません。 Section 2.3.1のstatic tableはentryとindexが仕様で固定されています. DNS cacheはHPACKのencoding contextではありません.

**Explanation:** **never indexed**を指定したliteral header fieldは, compression tableへ入れないsensitiveな値に使います. RFC 7541はcredentialやcookieを代表例として挙げます. これらの例は, 漏れると再利用され得るbearer tokenまたはsession materialを含みます. bearer tokenは再利用可能なcredentialであり, compression stateへ保持すると露出面が増えます. このmedia-type preferenceは, 問題の例ではcredentialやsession identifierではありません. session cookieは後続requestをauthorizeし得るため, secretとして扱います. responseが設定するsession identifierも, 同種の再利用可能なsecretです. sensitivityは値とthreat modelで決まります. field nameだけを一律の規則として使うべきではありません.

**Explanation:** HTTP/2ではdecoderが**SETTINGS_HEADER_TABLE_SIZE**でmaximumを提示します. encoderは現在値をそれより小さくできますが, 上限を超えられません. acknowledgeされたsettingが, encoderのdynamic tableに対するprotocol上のmaximumです. decoderがpersistent compression stateとmemory commitmentを制約できます. static tableは別の固定tableであり, そのentry数はdynamic table capacityを決めません. header blockは複数frameにまたがり得るため, frame payload sizeはdynamic table capacityの上限ではありません. encoderはheader blockの先頭でdynamic table size updateを送り, 許容上限以下のcurrent sizeを示せます.

**解説:** Bが正解です。Section 5.2が許すpaddingは最大7 bitで、EOS symbolのmost significant bitsに一致するものだけです。7 bitを超えるpaddingやpatternの不一致はdecoding errorであり、encoded EOS symbolが含まれる場合もerrorです。 Aはmalformedなwire dataを黙ってnormalizeし、implementation間で同じblockの解釈が分かれる原因になります。Cのfallbackは仕様にありません。H bitが、そのbyteをどうdecodeするかを決めます。Appendix BがHuffman codeを固定していても、終端検証は省略できません。

**Explanation:** **compression oracle**は, attackerが入力の一部へ影響し, 同じcompression context内のsecretとの関係によるencoded lengthの変化を観測できる状況です. lengthを繰り返し比較すると, attacker-controlledなguessがsecretと構造を共有するか推定できる場合があります. side channelはsize behaviorを通じて情報を漏らしますが, HPACKがTLS traffic keyをheader blockへ入れるわけではありません. TLS recordはauthenticationできます. authenticated transportでもlength oracleは別の観測面として残り得ます. RFC 7541のsecurity considerationsが扱うprobing riskです. never-indexed表現やcompression contextの分離で一部のriskを減らせますが, attacker influenceを明示的に分析する必要があります.

**Explanation:** RFC 7541 Sections 7.1と7.1.1はこのattacker modelを直接扱います. mutually distrustfulなentityがcompression contextを共有し, 一方がencoded fieldへ影響しlengthを観測できる状況です. TLSはcontentを保護しますがdynamic-table probingに使えるlengthは残り, low-entropy secretほど推測されやすくなります. Sections 7.1.2と7.1.3はmitigationの選択肢を説明し、fieldを構築するentityごとのdynamic-table access分離をideal solutionとして示します。CookieとAuthorizationはnever-indexed literalを選び得るsensitive valueの例です。Section 6.2.3は、HPACKでre-encodeするintermediaryにnever-indexed representationの維持を要求します。 never-indexingはliteral lengthを隠さず, 全side channelを解決するものではありません. dynamic tableへの挿入と再利用を防ぐため, remaining length exposureやcompressionをterminate/recreateするhopは別途threat analysisが必要です.

**解説:** Cが正解です。Sections 7.3と7.4はdynamic-table stateとtemporary processing memoryを分けています。decoderはHTTP/2 settingでtable memoryを制限できますが、受理するinteger value、integer encoding length、string literal lengthにもlimitを設ける必要があります。application上の要件を考慮しつつ、sequential processingで一時memoryを減らせます。 Aは1種類のstate limitをdecoding中の全allocationと混同しています。Bはtransport framingとHPACK value limitを混同しています。header blockは複数frameにまたがる可能性があり、Section 7.4はなおimplementation limitを求めます。tableを0にすることは有用ですが、resource-exhaustion対策の全部ではありません。