ToppyMicroServices

RFC 9325 Quiz (JA)

TLS/DTLSを安全に使うための推奨事項

ENJA
0 / 0

参照（URL）

Q1: この新しいA2A application protocolに合うTLS version方針はどれか

単一選択

このprotocolはTCP上でTLSをchannel securityとして再利用し,現在のTLS libraryとの広い相互運用性を必要とします.新しいtransport protocol自体を定義するものではありません.

**解説:** A: RFC 9325 Section 3.1.1のTLS/DTLS 1.3だけを使う規則は,新しいtransport protocolに対するものです.TLSを再利用する新しいapplication protocolには別の規則があります. B: Section 3.1.1はTLS 1.2のsupportを要求し,TLS 1.3のsupportを推奨しますが,TLS 1.2だけを目標方針にはしていません. C: Section 3.1.1は相互運用性のため両versionを組み込み,TLS 1.3を実装する場合は優先し,TLS 1.1以前をnegotiationしないよう求めます. D: Section 3.1.1はTLS 1.0とTLS 1.1のnegotiationを禁止します.互換性はこのdowngrade pathの根拠になりません. 判断軸: 実際に設計するprotocolの種類へ規則を適用し,version floorとnegotiation preferenceを明記します.

Q2: このdynamic TLS upgradeをどうdeployすべきか

単一選択

A2A control protocolにはSTARTTLS相当のupgradeだけがあります.現在のagentはupgrade responseがないとplaintextのまま続行します.

**解説:** A: RFC 9325 Section 3.2は,dynamic upgradeだけを持つprotocolにstrict local policyを要求し,管理者がそれを使ってTLS未確立時のplaintextを禁止するよう求めます. B: grantは保護されていない通信のconfidentialityやintegrityを回復しません.Section 3.2はsecure channel確立前のstrippingとcommand injectionを対象にします. C: 再試行後のfallbackもdowngrade条件を残します.必要なのはupgradeを試した事実ではなく,TLSで保護された最終状態です. D: Section 3.2はdynamic upgradeだけを持つprotocolについて規定します.networkの所在だけで指定されたdowngrade riskは消えません. 判断軸: upgradeだけが経路なら,受理条件は保護された状態へ到達することです.upgrade失敗はconnection失敗です.

Q3: このsession ticket設計に対する適切なreview指摘はどれか

単一選択

gateway fleetは1個のsession-ticket encryption keyを90日間共有します.ticketも90日間有効で,退役gatewayはincident分析のため古いkeyを保持します.

**解説:** A: RFC 9325 Section 3.4はresumptionを別のhandshakeとして扱い,ticket key侵害がforward secrecyの利益を失わせ得ると説明します. B: identifier長は露出期間を制限しません.Section 3.4が重視するのは強いticket暗号化,key rotation,key破棄,妥当な有効期間です. C: 侵害時に利用可能な古いkeyの保持は,有効期間終了時の破棄要件に反します.同じkeyによる二重化もtrust windowを直しません. D: Section 3.4がこれらのcontrolを直接示します.目的はresumptionが最初のhandshakeのsecurity propertyを弱めないことです. 判断軸: session ticketは最初のhandshake有無ではなく,secretとその露出期間でreviewします.

Q4: このstate-changing A2A operationでTLS 1.3 0-RTTを使えるか

単一選択

agentはcreditを移転するnon-idempotent taskを0-RTT dataとして送ります.A2A profileにはTLS 1.3を使うとの記載しかなく,replay処理や対象operationを定めていません.

**解説:** A: grant validityとreplay resistanceは独立です.認可済みrequestの複製でも同じstate changeを複数回起こせます. B: RFC 9325 Section 3.10は,適切で安全な条件を説明する明示的仕様がなければapplicationが0-RTTを避けるよう求めます.このprofileにはその規則がありません. C: session ticketはresumptionを可能にしますが,application-levelのexactly-once recordではありません.replay-awareなoperation ruleが別途必要です. D: Section 3.10は一律禁止ではありません.明示的なapplication仕様が安全な利用を定めれば0-RTTを利用できます. 判断軸: 判定条件はTLS 1.3そのものではなく,明示的なprotocol ruleと対象operationのreplay-safeな処理です.

Q5: このgateway終端TLSからbackendが結論できることは何か

単一選択

mutual TLSはagentをgatewayへ認証します.gatewayはbackendへ別のTLS connectionを開き,client certificateから転記したunsigned X-Agent-Identity headerを送ります.

**解説:** A: 2本のhop-by-hop TLS channelは1本のTLS channelになりません.第2区間で認証されるendpointはgatewayであり,元agentではありません. B: cipherとversionのcheckはchannelを保護しますが,unsigned application headerを以前のchannelに関する真正な主張にはしません. C: RFC 9325 Section 5.1はTLS authenticationをTLS communicationのendpointについて定義します.systemはgateway assertionの保護と信頼を別途定める必要があります. D: RFC 9325はgatewayでのTLS終端を禁止していません.問題はintermediary自体ではなく,新しいtrust boundaryを越えるclaimです. 判断軸: 各identity claimを認証したchannelへ対応付け,boundaryを越えるassertionの保護とtrustを明記します.

Q6: この高impact A2A pathに十分なcomposition ruleはどれか

単一選択

gatewayはTLS 1.3 resumptionを使い,0-RTT taskを受ける場合があります.grantとsession-bound proofを検証し,resource判断を行うbackendへidentity assertionを転送します.

**解説:** A: RFC 9325 Sections 3.4と3.10はresumptionとearly dataを扱い,Section 5.1はTLS security serviceをendpointへ限定します.grant,proof,resource authorizationは独立したapplication checkです. B: grantはreplay safetyもTLS session identityも提供しません.長期間共有するticket keyはSection 3.4の露出制御にも反します. C: early dataを除くことは1個のriskを直しますが,ticket key windowとgateway越しidentity assertionは未評価のままです. D: このBCPはtransport-security floorであり,authorization protocolではありません.proof inputやbackend trust modelを暗黙に定義できません. 判断軸: compositionを受理するには,各保証についてendpoint,freshnessまたはreplay rule,verification input,final decision ownerを特定します.