RFC 9325 Quiz (EN)

Q1: Which TLS version policy fits this new A2A application protocol?

Multiple Choice

The protocol runs over TCP, reuses TLS for channel security, and needs broad interoperability with current TLS libraries. It is not defining a new transport protocol.

A. Require TLS 1.3 only, because every newly designed protocol is barred from integrating TLS 1.2. B. Require TLS 1.2 only, because TLS 1.3 is optional whenever existing libraries must interoperate. C. Integrate TLS 1.2 and TLS 1.3, prefer TLS 1.3 when available, and do not negotiate older versions. D. Offer TLS 1.3 first but allow fallback through TLS 1.1 when a legacy agent cannot complete the handshake.

**Explanation:** A: RFC 9325 Section 3.1.1 reserves the TLS/DTLS 1.3-only rule for new transport protocols. It gives a different integration rule for new application protocols that reuse TLS. B: Section 3.1.1 requires TLS 1.2 support and recommends TLS 1.3 support, but it does not make TLS 1.2-only the target policy. C: Section 3.1.1 says new application protocols should integrate both versions for interoperability, must prefer TLS 1.3 when implemented, and must not negotiate TLS 1.1 or earlier. D: Section 3.1.1 forbids negotiation of TLS 1.0 and TLS 1.1. Compatibility does not justify this downgrade path. Decision rule: Apply the rule for the kind of protocol actually being designed, then state the version floor and negotiation preference explicitly.

Q2: How should this dynamic TLS upgrade be deployed?

Multiple Choice

An A2A control protocol has only a STARTTLS-like upgrade. Today, an agent continues in plaintext when the upgrade response is missing.

A. Provide and enable a strict local policy that forbids plaintext when TLS is not negotiated, causing the connection to fail. B. Continue in plaintext only for authenticated grants, because application authentication compensates for a stripped upgrade. C. Retry the upgrade once and then continue in plaintext, because the peer might not implement the extension. D. Permit plaintext on private networks, because the strict-upgrade guidance applies only to public web browsers.

**Explanation:** A: RFC 9325 Section 3.2 requires a strict local policy when dynamic upgrade is the only method, and administrators must use it to forbid plaintext without negotiated TLS. B: A grant does not restore confidentiality or integrity to the unprotected exchange. Section 3.2 targets stripping and command-injection attacks before the secure channel exists. C: Falling back after a retry preserves the downgrade condition. The required end state is a TLS-protected channel, not a best-effort attempt to upgrade. D: Section 3.2 states the rule for protocols with only a dynamic upgrade method. Network location does not remove the specified downgrade risk. Decision rule: When upgrade is the only path, acceptance depends on reaching the protected end state; a failed upgrade is a failed connection.

Q3: Which review finding is justified for this session-ticket design?

Multiple Choice

A gateway fleet shares one session-ticket encryption key for 90 days. Tickets remain valid for all 90 days, and retired gateways retain the old key for incident analysis.

A. Accept the design if the initial full handshake used TLS 1.3, because later ticket handling cannot weaken forward secrecy. B. Accept the shared key but shorten only the ticket identifier, because ticket confidentiality is independent of key lifetime. C. Keep the old key for audit recovery, but encrypt the ticket a second time with the same fleet-wide key. D. Require authenticated and encrypted resumption data, regular key rotation and destruction, and a bounded ticket lifetime tied to that rotation.

**Explanation:** A: RFC 9325 Section 3.4 treats resumption as another handshake and warns that ticket-key compromise can negate forward-secrecy benefits. B: Identifier length does not bound the exposure window. Section 3.4 focuses on strong ticket encryption, key rotation, key destruction, and reasonable validity. C: Retaining a compromised-capable key defeats the required destruction at the end of its validity period. Reusing that key for another layer does not fix the trust window. D: Section 3.4 directly supplies these controls. Their purpose is to keep resumption from weakening the security properties of the initial handshake. Decision rule: Review session tickets by the secrets and time window they expose, not merely by whether the first connection was a full handshake.

Q4: May this state-changing A2A operation use TLS 1.3 0-RTT?

Multiple Choice

An agent sends a non-idempotent task that transfers credits as 0-RTT data. The A2A profile says only that TLS 1.3 is used; it defines no replay handling or operation eligibility.

A. Yes, if the grant is unexpired, because authorization validity also proves that the request was not replayed. B. No under the current profile; 0-RTT needs explicit protocol rules that define when it is appropriate and secure, including replay consequences. C. Yes, if the server stores the TLS session ticket, because ticket uniqueness makes every early-data request execute once. D. No for every A2A operation in all deployments, because RFC 9325 permanently prohibits application protocols from using 0-RTT.

**Explanation:** A: Grant validity and replay resistance are independent. A copied authorized request can still cause the same state change more than once. B: RFC 9325 Section 3.10 says applications must avoid 0-RTT unless an explicit specification explains when it is appropriate and secure. This profile has no such rule. C: A session ticket enables resumption; it is not an application-level exactly-once record. The design still needs replay-aware operation rules. D: Section 3.10 does not impose a universal ban. It permits 0-RTT when an explicit application specification establishes safe use. Decision rule: The decision criterion is not TLS 1.3 alone; it is an explicit protocol rule plus replay-safe handling for the particular operation.

Q5: What can the backend conclude from this gateway-terminated TLS connection?

Multiple Choice

Mutual TLS authenticates an agent to a gateway. The gateway then opens a separate TLS connection to a backend and sends an unsigned X-Agent-Identity header copied from the client certificate.

A. The backend has end-to-end mutual TLS with the agent because both network legs independently use TLS. B. The backend can treat the header as the client certificate whenever the gateway passed RFC 9325 cipher checks. C. RFC 9325 protects each TLS channel, but the client identity assertion across the gateway needs a defined trust boundary and integrity protection. D. The backend has no usable security property at all, because terminating TLS at an intermediary is forbidden by the BCP.

**Explanation:** A: Two hop-by-hop TLS channels do not form one TLS channel. The authenticated endpoint on the second leg is the gateway, not automatically the original agent. B: Cipher and version checks protect the channel but do not authenticate an unsigned application header as a statement about the prior channel. C: RFC 9325 Section 5.1 defines TLS authentication in terms of an endpoint of the TLS communication. The system must separately protect and authorize the gateway assertion. D: RFC 9325 does not prohibit TLS termination at gateways. The issue is the claim carried across the resulting trust boundary, not the existence of an intermediary itself. Decision rule: Map every claimed identity to the channel on which it was authenticated, then specify how any cross-boundary assertion is protected and trusted.

Q6: Which composition rule is sufficient for this high-impact A2A path?

Multiple Choice

A gateway uses TLS 1.3 resumption and may receive 0-RTT tasks. It validates a grant and a session-bound proof, then forwards an identity assertion to a backend that performs the resource decision.

A. Control ticket keys and lifetimes, permit 0-RTT only for explicitly replay-safe tasks, bind the proof to the accepted session, and protect the assertion used by backend authorization. B. Treat a valid grant as permission to use 0-RTT, reuse ticket keys for operational simplicity, and let the backend infer the original session from the gateway hostname. C. Disable 0-RTT but keep indefinite shared ticket keys, then accept the forwarded identity because every request arrived on some TLS-protected connection. D. Meet the RFC 9325 version and cipher floor, then omit application proof and backend trust rules because TLS endpoint authentication supplies both decisions.

**Explanation:** A: RFC 9325 Sections 3.4 and 3.10 cover resumption and early data, while Section 5.1 bounds TLS security services to its endpoints. Grant, proof, and resource authorization remain separate application checks. B: A grant does not provide replay safety or identify a TLS session. Long-lived shared ticket keys also conflict with the exposure controls in Section 3.4. C: Removing early data addresses one risk but leaves the ticket-key window and the cross-gateway identity assertion unevaluated. D: The BCP is a transport-security floor, not an authorization protocol. It cannot silently define proof inputs or the backend trust model. Decision rule: A composed design is acceptable only when each guarantee names its endpoint, freshness or replay rule, verification input, and final decision owner.

Recommendations for Secure Use of TLS and DTLS

References (URLs)

Q1: Which TLS version policy fits this new A2A application protocol?

Q2: How should this dynamic TLS upgrade be deployed?

Q3: Which review finding is justified for this session-ticket design?

Q4: May this state-changing A2A operation use TLS 1.3 0-RTT?

Q5: What can the backend conclude from this gateway-terminated TLS connection?

Q6: Which composition rule is sufficient for this high-impact A2A path?