RFC 5705 Quiz (EN)

Q1: Which inputs define RFC 5705 exported keying material?

Multiple Choice

Two TLS 1.2 peers want to derive the same application-specific 32-byte value from their established TLS session.

A. Only the negotiated cipher suite and desired output length B. The TLS session, label, context or its absence, and output length C. The peer certificate subject, HTTP authority, and token audience D. Any shared application string, provided both peers call it an exporter

**Explanation:** A: The cipher suite participates through the TLS session, but it does not identify the application purpose or context. B: RFC 5705 Section 4 defines the exporter using TLS-session state plus a label, a context value when provided, and a requested length. Absence of context uses a different construction from a provided zero-length context. Both peers need the same inputs for the same output. C: An application may encode selected semantics into its context, but those fields are not implicit exporter inputs. D: A shared string not derived with the specified exporter construction is not exported keying material.

Q2: How should an application establish exporter purpose and context?

Multiple Choice

An A2A protocol negotiates an exporter use after the TLS handshake. Its context includes a task identifier sent in an application message.

A. Reuse a generic label for every feature because the context alone always prevents cross-protocol use B. Omit negotiation because TLS Finished already covers all post-handshake application messages C. Let each peer normalize the task identifier independently as long as it recognizes the same task D. Use an application-specific label and securely agree the exact context encoding before using the output

**Explanation:** A: RFC 5705 Sections 3 and 5 use labels for purpose separation; a generic label weakens that separation. B: Section 3 notes that upper-layer messages used to establish context are not automatically covered by TLS Finished. C: Semantically similar but byte-distinct contexts produce different outputs and can create interpretation gaps. D: Section 3 requires the application context to be securely established and the exporter use to be signaled; the label identifies the application purpose.

Q3: Can a backend treat forwarded exporter bytes as its own channel evidence?

Multiple Choice

A gateway terminates a client TLS 1.2 session, derives RFC 5705 output, and forwards the bytes to a backend over another TLS session. The backend wants to use them as proof that the client shares keying material with the backend connection.

A. Yes, because exporter output remains associated with any later TLS channel carrying the same bytes B. Yes, if the gateway and backend use the same exporter label on their independent sessions C. No. Output is scoped to the client-gateway session; the backend may instead trust a protected gateway assertion D. No, because RFC 5705 forbids exporter output from being transported by an application

**Explanation:** A: RFC 5705 Section 4 associates output with one TLS session, label, and context; transport does not change its origin. B: Equal labels on sessions with different TLS state do not make the outputs evidence of one shared channel. C: This preserves the exporter scope and separates it from a gateway trust model. The assertion's integrity, authentication, and semantics belong to the A2A profile. D: An application can use or transport derived values subject to its security design; the error is the claim attached to the forwarded value.

Q4: How should two exporter purposes be separated?

Multiple Choice

The same TLS session derives a 32-byte request-proof key and a 32-byte audit-chain key. The draft uses the identical label and context for both, then distinguishes them only by the calling function.

A. Keep the inputs because different calling functions make the derived keys cryptographically independent B. Use distinct application labels, plus separate contexts when additional instance separation is needed C. Keep one label but compare the operation name only after each key has been used D. Request different output lengths and truncate both results to 32 bytes

**Explanation:** A: Identical exporter inputs on one session produce the same material regardless of the caller's function name. B: RFC 5705 Section 5 says the same label with the same master secret must not be used for different purposes. Distinct labels provide purpose separation; context serves the profile-defined role described in Sections 3 and 4. C: A post-derivation comparison cannot undo key reuse. D: Length manipulation is not a substitute for disjoint purpose labels and can create overlapping material.

Q5: Does RFC 5705 independence make logging this MAC key safe?

Multiple Choice

An A2A service derives an exporter value and uses it directly as the MAC key for request proofs. For diagnostics it writes that value to a log readable by the operations team. The team argues that RFC 5705 exporter independence makes this safe.

A. Yes; exporter independence makes disclosed output unusable for computing application MACs B. Yes, if TLS traffic secrets are not logged alongside it C. Yes, if the log entry omits the exporter label and context D. No. The logged value is the MAC key for that purpose despite its separation from TLS traffic keys

**Explanation:** A: Independence limits compromise between exporter uses and TLS internals; it does not revoke a disclosed key. B: Keeping traffic secrets private does not preserve the confidentiality of the logged application key. C: The key itself is sufficient for its direct MAC use in this design. D: RFC 5705 Section 5 discusses independence properties. Those properties do not make exporter output public; application handling must protect material according to how it is used.

Q6: How should a gateway retry preserve an exporter-bound proof?

Multiple Choice

A client sends a valid grant and a proof derived from TLS session A to a gateway. The gateway retries the request to a backend over TLS session B. The backend owns the resource and must know whether the proof covered the retried method, target, and body.

A. Verify at the gateway and protect a request-bound assertion, or use backend-verifiable end-to-end proof; session A is not session B B. Reuse session A exporter bytes on session B because a valid grant preserves the TLS binding C. Derive new output on session B and call it the client's proof because the label and context can remain unchanged D. Verify only the grant at the backend because grant validity implies both exporter possession and request integrity

**Explanation:** A: RFC 5705 Section 4 scopes output to its TLS session and exporter inputs. The two alternatives accurately place the verifier and trust boundary while preserving request context. Backend authorization remains separate. B: Grant validity and TLS-session binding are independent guarantees. C: Session B output proves knowledge at the session B endpoints, not at the original client endpoint. D: A grant does not by itself prove exporter possession or integrity of the retried request.

Keying Material Exporters for TLS

References (URLs)

Q1: Which inputs define RFC 5705 exported keying material?

Q2: How should an application establish exporter purpose and context?

Q3: Can a backend treat forwarded exporter bytes as its own channel evidence?

Q4: How should two exporter purposes be separated?

Q5: Does RFC 5705 independence make logging this MAC key safe?

Q6: How should a gateway retry preserve an exporter-bound proof?