RFC 9266 Quiz

Q1: What is the purpose of the tls-exporter channel binding?

Multiple Choice

A. To replace TLS record encryption B. To bind upper-layer authentication to a specific TLS connection C. To publish the TLS private key to the application

**Explanation:** A: Channel binding data is an input to upper-layer authentication, not a record cipher. B: The exported value lets both endpoints associate the upper-layer exchange with the channel instance. C: The exporter derives non-secret binding data and does not expose the TLS private key.

Q2: Which inputs define the RFC 9266 tls-exporter value?

Multiple Choice

A. A random application label, the user ID, and 64 bytes B. The server certificate bytes with no exporter call C. Label EXPORTER-Channel-Binding, empty context, and 32 bytes

**Explanation:** A: Arbitrary inputs would not produce the interoperable channel-binding value. B: RFC 9266 uses TLS exported keying material rather than a certificate hash. C: These fixed exporter inputs define the registered tls-exporter binding.

Q3: Is tls-exporter channel-binding data a secret key?

Multiple Choice

A. No, it must not be used as a key for privileged information B. Yes, applications should encrypt databases directly with it C. Yes, but only the client may read it

**Explanation:** A: RFC 9266 says disclosure does not harm TLS and prohibits secret-key reuse. B: The derived data is limited to channel-binding use. C: Both channel endpoints need corresponding binding data and it is registered as non-secret.

Q4: What uniqueness does tls-exporter provide?

Multiple Choice

A. A permanent global identifier for the server B. Uniqueness for the specific TLS connection C. A unique value for every HTTP stream on one connection

**Explanation:** A: The value identifies a TLS connection instance, not a stable server identity. B: RFC 9266 provides the RFC 5056 connection-level form of uniqueness. C: The base channel binding does not distinguish upper-layer stream or mechanism instances.

Q5: One TLS connection carries an upper-layer authentication exchange. Which lifecycle matches RFC 9266?

Multiple Choice

A. Reuse the connection for later mechanisms when they share the same username B. Reuse the connection because the exporter value acts as a per-mechanism secret C. Use one mechanism instance and close the connection when that upper-layer exchange concludes

**Explanation:** A: User identity does not create cryptographic separation between mechanism instances. B: The value is non-secret and lacks per-mechanism instance separation. C: RFC 9266 requires this lifecycle because its binding is only connection-unique.

Q6: What must a TLS 1.3 implementation support if it implements channel binding?

Multiple Choice

A. tls-exporter B. tls-unique only C. A certificate fingerprint chosen by each application

**Explanation:** A: RFC 9266 makes tls-exporter mandatory to implement when channel bindings are supported over TLS 1.3. B: tls-unique is not defined as the TLS 1.3 binding. C: Application-specific fingerprints are not the registered interoperable binding.

Q7: When is tls-exporter defined with respect to master secrets?

Multiple Choice

A. For every legacy TLS connection regardless of extensions B. When the handshake produces unique master secrets, always true for TLS 1.3 C. Only after the application sends a bearer token

**Explanation:** A: Legacy TLS needs additional precautions such as extended master secret. B: TLS 1.3 provides the required property while older versions need the appropriate extension. C: Token presentation is unrelated to whether the TLS exporter is defined.

Q8: What is the rule when TLS renegotiation is enabled on a connection?

Multiple Choice

A. Use the exporter from the first handshake forever B. Concatenate exporter values from each renegotiation C. Do not support tls-exporter on that connection

**Explanation:** A: RFC 9266 does not define such a selection rule. B: No concatenation construction is specified. C: RFC 9266 says the binding is not defined when renegotiation is enabled.

Q9: Does a matching tls-exporter value prove an application's authorization policy was satisfied?

Multiple Choice

A. No, it proves a channel association used by an upper-layer protocol B. Yes, because the TLS server selected the user's scope C. Yes, if the connection uses a public certificate

**Explanation:** A: The upper layer must still authenticate principals and evaluate authorization. B: TLS exporters do not carry OAuth scope decisions. C: Certificate validation and application authorization remain distinct from the exporter value.

Q10: An A2A protocol multiplexes many independent sessions over one TLS connection. What additional design issue arises?

Multiple Choice

A. The exporter automatically creates a distinct value for each A2A session B. The profile needs explicit per-session separation or a one-instance lifecycle C. The sessions no longer need application authentication

**Explanation:** A: RFC 9266 fixes one connection binding and does not add session context. B: Without separation, a connection-level binding can be replayed across upper-layer instances. C: Multiplexing and channel binding do not replace principal authentication.

The tls-exporter binding and its connection boundary

References

Q1: What is the purpose of the tls-exporter channel binding?

Q2: Which inputs define the RFC 9266 tls-exporter value?

Q3: Is tls-exporter channel-binding data a secret key?

Q4: What uniqueness does tls-exporter provide?

Q5: One TLS connection carries an upper-layer authentication exchange. Which lifecycle matches RFC 9266?

Q6: What must a TLS 1.3 implementation support if it implements channel binding?

Q7: When is tls-exporter defined with respect to master secrets?

Q8: What is the rule when TLS renegotiation is enabled on a connection?

Q9: Does a matching tls-exporter value prove an application's authorization policy was satisfied?

Q10: An A2A protocol multiplexes many independent sessions over one TLS connection. What additional design issue arises?