RFC 5705 Quiz (JA)

**判断のポイント:** TLS exporterの役割を, 近いが別のsecurity機能やpolicy判断から切り分けます. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: TLS private keyをapplication layerへexportすることはRFC 5705の中心目的ではありません. 近い設計では関係しても, このRFCが直接解く判断ではありません. - B: 確立済みTLS connectionからapplication固有のkeying materialを導出することがこのRFCを読む主な理由です. 実装やreviewではここから入力, 検証, 境界を確認します. - C: TLSから導出したbyteすべてへauthorization上の意味を自動で与えることは範囲外です. RFC 5705だけで上位policyや別protocolの責務までは決まりません.

**判断のポイント:** TLS exporterは部品です. 受理条件, authorization, deployment例外は明示する必要があります. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: exported byteがapplication protocol内で何をauthorize, identify, bindするかはRFC本文だけでは決まりません. relying applicationが何を成功とするかを指定します. - B: local acceptance policyを省略すると, validな形式を誤ったcontextで受理できます. これはRFCの境界を越えています. - C: derived byteを比較する前に, 両peerが同じlabel, context, length, connectionを使うことを確認するは実装reviewで残すべき境界です. 入力元とscopeを確認しないと誤受理につながります. - D: RFC参照は安全性の必要条件になり得ますが, deployment設定, 鍵, trust, failure handlingまで自動では保証しません.

**判断のポイント:** profileはTLS exporterの使い方を実装間で同じにするためのcontractです. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: 入力byteやcontextを自由にすると, 実装ごとに別の値を検証してしまいます. - B: human-readable textは説明には使えますが, validationのstable inputにするとlocaleや文言変更で壊れます. - C: ここでは, application目的に対して衝突しにくいexporter labelとcontext stringを定義することが必要です. producer側の規則が明確なら, verifierは同じ条件で検証できます.

**判断のポイント:** 相互運用性の問題は, 同じwire dataを違う意味で処理したときに表面化します. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: 異なるlabel, context, connectionで導出したexporter byteを比較することは検証対象やmeaningをずらします. その結果, 実装間で成功条件が合わなくなります. - B: BCP 14を要件へ限定することは, 仕様の曖昧さを減らす側の行動です. - C: unsupported extensionの扱いを文書化することは, 実装差を減らすために有効です.

**判断のポイント:** TLS exporterは受信経路だけでなく, 定義されたinputとscopeで検証される必要があります. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: HTTPSはtransport保護には有効ですが, TLS exporterの個別validationを置き換えません. - B: derived byteを比較する前に, 両peerが同じlabel, context, length, connectionを使うことを確認するが中心です. これによりwell-formedな入力と受理可能な入力を分けられます. - C: filenameやpathはrouting hintにはなりますが, identityやsecurity proofとしては不足します.

**判断のポイント:** 仕様が処理規則を定義しても, どの結果を受理するかは別のpolicy判断です. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: exporter label, context value, output length, TLS connection secretはRFC 5705が直接扱う中核です. policyではなくmechanism側の内容です. - B: exported byteがapplication protocol内で何をauthorize, identify, bindするかはapplicationまたはdeploymentが決める受理条件です. - C: well-formed syntaxやalgorithm処理はRFCが定義する側です. ただし成功結果の意味は別途決めます. - D: exporter outputをどうencodeしtransportするかはlocal policyです. 運用とthreat modelに合わせて明文化します.

**判断のポイント:** security reviewでは, mechanismを入れた事実よりも, 誤った条件で受理する経路を見ます. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: performanceは重要な場合がありますが, cacheでsecurity propertyを代替する判断は危険です. - B: 新しいlibraryは有利ですが, local policy, input, threat modelのreviewは残ります. - C: 異なるprotocol目的でgeneric labelを使い回すこと, separationが必要な場面でcontextを省くことが中心的な失敗モードです. 攻撃者はここを使ってcontextやtrustをずらします.

**判断のポイント:** 隣接仕様は置き換え関係ではなく, layerや責務の違いとして読むのが安全です. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: RFC 5705は古いTLS利用向けexporterを定義し, 後続のTLS 1.3 channel bindingはexporterの考え方に基づくという読み方が責務分担を壊しません. - B: obsolete関係はRFC本文で明示されるものです. 近いconceptだから置き換えとは限りません. - C: TLS exporterはprotocol compositionのreviewで意味を持ちます. 無関係として扱うと境界を見落とします.

**判断のポイント:** review questionは, 実装者が同じ成功/失敗境界を再現できるかを確認するために使います. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: input, context, validation rule, rejection behaviorの明記は, 実装差を減らす直接的なcheckです. - B: RFC番号だけではlocal semanticsは決まりません. profileやpolicyで補う必要があります. - C: unknown valueをsuccessにすると, extensionや攻撃入力を誤って受理できます. - D: application proofやkey confirmation valueをTLS sessionへ結び付ける場面は現実のreview対象です. ここで成功条件を固定すると誤用を減らせます.

**判断のポイント:** validation失敗は, その入力を根拠にした判断を止める信号です. **関連キーワード:** - **exporter label**: 用途を分ける名前 - **context**: 追加の分離入力 - **keying material**: TLSから導出するbyte列 **選択肢:** - A: warningへ下げて受理するとfail openになります. 攻撃入力でも成功経路へ入れます. - B: そのsecurityまたはpolicy decisionには使えないと扱うのが安全です. 必要なら明示的なfallback policyを別に定義します. - C: authorizationは重要ですが, 壊れたvalidation inputを自動修復するものではありません.