ToppyMicroServices

RFC 8446 Quiz

TLS 1.3 security properties

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

Primary reference

These questions separate handshake authentication, key-exchange properties, 0-RTT policy, traffic-key state, exporter scope, and downstream authorization. Section numbers refer to RFC 8446.

Q1: Which key exchange property is a baseline design goal in TLS 1.3

Multiple Choice

An attacker records certificate-authenticated TLS 1.3 connections that use fresh ECDHE shares, then later obtains the server's long-term certificate private key. The review asks which property limits retrospective decryption.

RFC 8446 Section 1.2 removes static RSA and static Diffie-Hellman key exchange. Public-key-based exchanges use fresh (EC)DHE shares, so later compromise of a long-term authentication key does not by itself reveal the shared secret of an earlier connection. Forward secrecy is not automatic in every TLS 1.3 mode. A PSK-only exchange does not provide it for application data, while combining the PSK with (EC)DHE can. A reviewer must therefore inspect the negotiated key-exchange mode, not infer the property from the TLS version alone.

Q2: What is the primary security risk of 0-RTT early data

Multiple Choice
RFC 8446 Section 8 states that TLS does not provide inherent replay protection for 0-RTT data. An attacker can cause the same early-data bytes to be processed more than once under conditions described in that section; certificate expiration is not the distinguishing issue. Applications should accept early data only when repeated execution has no unacceptable effect and should apply replay defenses suitable for the deployment. Idempotence is relevant, but it does not by itself prove that every replay is harmless across authorization, rate-limit, and backend boundaries.

Q3: TLS 1.3 derives keys through which general construction

Multiple Choice

An implementation proposes encoding the shared secret once and reusing one AEAD key for handshake and application traffic in both directions. The reviewer must select the TLS 1.3 construction that replaces this design.

RFC 8446 Section 7 defines an HKDF-based key schedule. `HKDF-Extract` combines input keying material at successive stages, and `HKDF-Expand-Label` derives purpose-specific secrets and keys, including separate handshake and application traffic secrets for each direction. Base64 only changes representation and cannot provide key derivation or domain separation. Reusing one traffic key across stages would also discard the separation that the TLS 1.3 schedule is designed to provide.

Q4: How are TLS 1.3 handshake messages sent after ServerHello protected

Multiple Choice

A packet trace shows EncryptedExtensions and Certificate in plaintext after ServerHello. The reviewer must determine the expected protection boundary.

TLS 1.3 keeps the early handshake visible through ServerHello. The key schedule then establishes traffic secrets that protect subsequent handshake messages.
ClientHello initial plaintext negotiate ServerHello key share chosen derive secrets Handshake traffic keys active protect later handshake
After ServerHello, the peers have the inputs needed to derive handshake traffic secrets. RFC 8446 then carries the remaining handshake messages in records protected with the corresponding handshake traffic keys; compression is not the protection mechanism. This reduces plaintext exposure of certificate and extension information compared with earlier handshakes. ClientHello and ServerHello remain visible because they are needed to establish the parameters from which those secrets are derived.

Q5: May the backend treat this header as original client-authentication evidence?

Multiple Choice

An A2A gateway terminates mutually authenticated TLS, validates the client certificate, and forwards an unsigned X-Agent-ID header over a separate gateway-to-backend TLS connection. The backend policy requires evidence that the original client authenticated.

A: RFC 8446 Sections 5 and 7.3 protect records on one TLS connection and do not automatically protect a derived header on another. B: The second TLS connection authenticates its own peer according to its mode, not the original client named in an arbitrary header. C: Make the gateway an explicit trust boundary with a protected assertion and defined semantics, or pass evidence the backend can validate. D: RFC 8446 defines TLS connections; it does not ban gateway architectures. Authorization and delegated identity remain application-profile decisions.

Q6: Which resumption mode meets the stated forward-secrecy criterion?

Multiple Choice

A profile uses a resumption PSK but requires fresh ephemeral key agreement so that PSK-only compromise does not expose the new connection's application traffic.

A: Section 2.2 says PSK-only use loses forward secrecy for application data. B: Sections 2.2 and 4.2.9 define `psk_dhe_ke` as PSK plus (EC)DHE, with both sides supplying `key_share`; that matches the criterion. C: TLS 1.3 removed static RSA key transport. D: The modes differ precisely in whether fresh (EC)DHE input contributes to the new connection.

Q7: Which execution decision is justified by RFC 8446

Multiple Choice

An A2A client sends a funds-transfer POST as TLS 1.3 0-RTT data. Replay caches are isolated per edge zone, and a rejected early-data request is retried as 1-RTT in another zone. The service claims successful TLS authentication proves at-most-once execution.

C is the defensible decision. RFC 8446 Sections 2.3 and 8 state that 0-RTT has weaker security properties and no inherent protection against replay across connections. Successful TLS authentication therefore does not establish at-most-once execution. Isolated replay state and a cross-zone retry path can still let the application observe the operation more than once. Appendix E.5 requires an application profile using 0-RTT to identify which messages are safe and to define appropriate handling. For a transfer, the service can use 1-RTT, or it can define application-level semantics such as a protected operation identifier with deduplication across every execution path. RFC 8446 does not mandate that particular design, and even its anti-replay mechanisms do not turn TLS authentication into a general transaction guarantee.

Q8: What must happen to early data after this HelloRetryRequest?

Multiple Choice

A client sends a first ClientHello with early_data and 0-RTT application records. The server responds with HelloRetryRequest for a different key share.

A: Section 4.1.2 requires removal of `early_data` from the follow-up ClientHello. B: Section 4.2.10 does not permit partial early-data acceptance. C: Early data is not permitted after HelloRetryRequest, and the server skips the first-flight application-data records up to the configured limit. D: HelloRetryRequest is a defined handshake path; a second retry request on the same connection would be an error.

Q9: How should the stack handle this ALPN change?

Multiple Choice

A ticket was established with ALPN h2. On resumption the client sends an h2 request as 0-RTT, but the new handshake selects ALPN a2a/1.

A: Section 4.2.10 requires the selected ALPN to match the value associated with the PSK before accepting early data. B: A TLS implementation MUST NOT automatically resend early data when ALPN differs; the application may need to construct a different message. C: The server cannot accept only a subset of early-data messages. D: Reject the 0-RTT data, finish the handshake, and let the application decide whether and how to issue an a2a/1 request.

Q10: Which KeyUpdate state transition is correct?

Multiple Choice

After Finished, peer A sends KeyUpdate(update_requested). Peer B receives it before sending its next Application Data record.

A: After sending KeyUpdate, A sends traffic with the next-generation keys. B: Section 4.6.3 requires B to update its receiving keys and, for `update_requested`, send KeyUpdate(`update_not_requested`) before its next Application Data. C: Sending and receiving traffic secrets are independent; B's sending-key update is signaled by its response. D: KeyUpdate advances application traffic secrets without restarting certificate authentication.

Q11: May the backend treat the forwarded exporter as its client-session binding?

Multiple Choice

A client and gateway derive a regular TLS exporter and use it in a session-bound proof. The gateway validates the proof, then forwards the exporter value and identity to a backend over a separate TLS connection. The backend never participates in the client-gateway handshake.

A: Section 7.5 derives the exporter from a particular session secret, label, and context; forwarding the value does not move that session. B: A separate backend connection has its own handshake context. C: The gateway can make a new protected assertion under an explicit trust model, or the backend can receive evidence bound to what it verifies; it must not call forwarded bytes its own client TLS binding. D: RFC 8446 explicitly defines exporters for application use. RFC 8446 does not choose the gateway trust model for the application.

Q12: Does this resumed connection prove a fresh certificate signature?

Multiple Choice

A server resumes with a PSK. The handshake contains pre_shared_key and Finished but no Certificate or CertificateVerify. An application policy requires a fresh proof using the server certificate key on this handshake.

A: Section 2.2 shows that a server authenticating via PSK does not send Certificate or CertificateVerify. B: Finished is a transcript MAC derived from handshake secrets, not a certificate-key signature. C: The PSK cryptographically ties resumption to its established context, but it does not satisfy the stated requirement for a fresh CertificateVerify on this handshake. D: The PSK does authenticate the server under the PSK trust context; the failure is relative to the application's stronger certificate-signature criterion.