ToppyMicroServices

RFC 8446 Quiz

TLS 1.3のセキュリティ特性

🇺🇸 🇯🇵
0 / 0

一次資料

handshake authentication、key-exchange property、0-RTT policy、traffic-key state、exporter scope、downstream authorizationを分けて扱います。Section番号はRFC 8446を指します。

Q1: TLS 1.3の基礎設計目標として代表的な性質はどれ

Multiple Choice

attackerはfresh ECDHE shareを使うcertificate-authenticated TLS 1.3 connectionを記録し、後にserverのlong-term certificate private keyを取得する。reviewerは過去通信の復号を制限するpropertyを確認する。

RFC 8446 Section 1.2はstatic RSAとstatic Diffie-Hellman key exchangeを廃止しています. public-key-based exchangeはfreshな(EC)DHE shareを使うため, 後から長期authentication keyが漏れても, それだけで過去connectionのshared secretは得られません. forward secrecyはTLS 1.3の全modeで自動的に得られるわけではありません. PSK-only exchangeはapplication dataにこの性質を提供せず, PSKと(EC)DHEを組み合わせた場合は提供できます. reviewerはTLS versionだけでなく, negotiated key-exchange modeを確認する必要があります.

Q2: 0-RTT early dataの主なリスクはどれ

Multiple Choice
RFC 8446 Section 8は, TLSが0-RTT dataへinherentなreplay protectionを提供しないと説明します. attackerは同じearly-data byteを複数回処理させ得ます. certificate expirationはこの性質を分ける論点ではありません. applicationはrepeated executionが許容できない作用を生まない場合に限ってearly dataを受理し, deploymentに合うreplay defenseを適用する必要があります. idempotenceは判断材料ですが, authorization, rate-limit, backend boundaryをまたぐ全replayが安全だとは証明しません.

Q3: TLS 1.3のkey scheduleは一般に何に基づく

Multiple Choice

implementationはshared secretを一度encodeし、handshakeとapplication trafficの両方向で1つのAEAD keyを再利用しようとする。reviewerはこの設計に代わるTLS 1.3のconstructionを選ぶ。

RFC 8446 Section 7はHKDF-based key scheduleを定義します. `HKDF-Extract`が各stageのinput keying materialを組み合わせ, `HKDF-Expand-Label`が用途別のsecretとkeyを導出します. handshakeとapplication, client方向とserver方向のtraffic secretも分離されます. Base64は表現を変えるだけで, key derivationやdomain separationを提供しません. 1つのtraffic keyを全stageで再利用する設計も, TLS 1.3 key scheduleの分離を失います.

Q4: ServerHelloより後に送るTLS 1.3 handshake messageはどう保護される

Multiple Choice

packet traceではServerHello後のEncryptedExtensionsとCertificateがplaintextになっている。reviewerは期待されるprotection boundaryを判断する。

TLS 1.3ではServerHelloまでが見えています. その後はkey scheduleからtraffic secretを導出し, 以降のhandshake messageを保護します.
ClientHello 初期の平文 交渉 ServerHello key share確定 secret導出 Handshake traffic key有効 以降を保護
ServerHello後は, peerがhandshake traffic secretの導出に必要なinputを得ています. RFC 8446は以降のhandshake messageを対応するhandshake traffic keyで保護したrecordとして送ります. compressionが保護機構なのではありません. これにより, earlier handshakeよりcertificateやextension informationの平文露出が減ります. ClientHelloとServerHelloは, secretを導出するparameterの確立に必要なので見えるままです.

Q5: backendはこのheaderをoriginal client-authentication evidenceとして扱えるか？

Multiple Choice

A2A gatewayはmutually authenticated TLSを終端し、client certificateを検証して、別のgateway-to-backend TLS connection上でunsigned X-Agent-ID headerを転送する。backend policyはoriginal clientがauthenticateしたevidenceを要求する。

A: RFC 8446 Sections 5と7.3のrecord protectionは1本のTLS connectionへ適用され、別connection上のderived headerを自動保護しません。B: 2本目のTLS connectionはそのmodeに従って自分のpeerをauthenticateし、任意headerに書かれたoriginal clientを証明しません。C: gatewayを明示的なtrust boundaryとしてprotected assertionとsemanticsを定義するか、backendが検証できるevidenceを渡します。D: RFC 8446はTLS connectionを定義しますがgateway architectureを禁止しません。authorizationとdelegated identityはapplication profileの判断です。

Q6: 指定したforward-secrecy基準を満たすresumption modeはどれか？

単一選択

profileはresumption PSKを使うが、PSK-only compromiseで新connectionのapplication trafficが露出しないよう、fresh ephemeral key agreementを要求する。

A: Section 2.2はPSK-only useがapplication dataのforward secrecyを失うと説明します。B: Sections 2.2と4.2.9は`psk_dhe_ke`をPSKと(EC)DHEの組合せとし、双方の`key_share`を要求するため基準に合います。C: TLS 1.3はstatic RSA key transportを廃止しました。D: 2つのmodeの違いは、fresh (EC)DHE inputが新connectionへ加わるかです。

Q7: RFC 8446から正当化できる実行判断はどれか

Multiple Choice

A2A clientが資金移動POSTをTLS 1.3の0-RTT dataで送ります. replay cacheはedge zoneごとに独立し, early dataが拒否されると別zoneへ1-RTTで再送します. serviceはTLS authenticationの成功がat-most-once実行を証明すると主張しています.

設計判断として妥当なのはCです. RFC 8446 Sections 2.3と8は, 0-RTTのsecurity propertyが弱く, connectionをまたぐreplayへのinherentな保護がないと説明します. したがってTLS authenticationの成功からat-most-once実行は導けません. replay stateがzoneごとに分かれ, 別zoneへの再送経路もあれば, applicationが同じoperationを複数回受ける可能性があります. Appendix E.5に従い, 0-RTTを使うapplication profileは安全なmessageとその扱いを定義する必要があります. 資金移動には1-RTTを使うか, 全実行経路で検証できる保護済みoperation IDとdeduplicationなどのapplication semanticsを設けられます. RFC 8446はその特定設計を一律に要求せず, anti-replay mechanismがあってもTLS authentication自体が一般的なtransaction保証になるわけではありません.

Q8: このHelloRetryRequest後、early dataをどう扱うか？

単一選択

clientはearly_data付きの最初のClientHelloと0-RTT application recordを送る。serverは別key shareを求めるHelloRetryRequestを返す。

A: Section 4.1.2はfollow-up ClientHelloから`early_data`を除くよう要求します。B: Section 4.2.10はearly dataの部分受理を許しません。C: HelloRetryRequest後はearly dataが許されず、serverはconfigured limitまでfirst-flight application-data recordをskipします。D: HelloRetryRequestは定義済みhandshake pathです。同一connectionで2回目のretry requestを受けることはerrorです。

Q9: stackはこのALPN変更をどう扱うか？

単一選択

ticketはALPN h2で確立された。resumption時にclientはh2 requestを0-RTTで送るが、新handshakeはALPN a2a/1を選択する。

A: Section 4.2.10はearly data受理前にselected ALPNがPSKに関連付けられた値と一致することを要求します。B: ALPNが異なる場合、TLS implementationはearly dataを自動再送してはなりません。applicationは別messageを構成する必要があります。C: serverはearly-data messageの一部だけを受理できません。D: 0-RTT dataをrejectしてhandshakeを完了し、a2a/1 requestを送るかとその構成はapplicationが判断します。

Q10: 正しいKeyUpdate state transitionはどれか？

単一選択

Finished後、peer AがKeyUpdate(update_requested)を送る。peer Bは次のApplication Data recordを送る前にそれを受信する。

A: KeyUpdate送信後、Aはnext-generation keyでtrafficを送ります。B: Section 4.6.3はBへreceiving keyの更新を要求し、`update_requested`なら次のApplication Dataより前にKeyUpdate(`update_not_requested`)を送らせます。C: sending traffic secretとreceiving traffic secretは独立し、Bのsending-key updateはresponseで通知されます。D: KeyUpdateはcertificate authenticationをやり直さずapplication traffic secretを進めます。

Q11: backendはforwarded exporterを自分のclient-session bindingとして扱えるか？

単一選択

clientとgatewayはregular TLS exporterをderiveし、session-bound proofへ使う。gatewayはproofを検証後、別TLS connectionでexporter valueとidentityをbackendへ転送する。backendはclient-gateway handshakeへ参加していない。

A: Section 7.5は特定session secret、label、contextからexporterをderiveします。value転送でsessionは移動しません。B: 別backend connectionには独自のhandshake contextがあります。C: gatewayは明示的trust modelの下で新しいprotected assertionを作るか、backendが自ら検証する対象へbindされたevidenceを受け取れます。forwarded byteをbackend自身のclient TLS bindingとは呼べません。D: RFC 8446はapplication利用のためexporterを定義します。gateway trust modelはRFC 8446ではなくapplicationが決めます。

Q12: このresumed connectionはfresh certificate signatureを証明するか？

単一選択

serverはPSKでresumeする。handshakeはpre_shared_keyとFinishedを含むが、CertificateとCertificateVerifyはない。application policyはこのhandshakeでserver certificate keyによるfresh proofを要求する。

A: Section 2.2はPSKでauthenticateするserverがCertificateとCertificateVerifyを送らないことを示します。B: Finishedはhandshake secretからderiveしたtranscript MACであり、certificate-key signatureではありません。C: PSKはresumptionを確立済みcontextへcryptographically bindしますが、このhandshake上のfresh CertificateVerifyという指定要件は満たしません。D: PSKはPSK trust contextの下でserverをauthenticateします。失敗するのはapplicationのより強いcertificate-signature基準です。