ToppyMicroServices

RFC 7301 Quiz

Application-Layer Protocol Negotiation

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

References (URLs)

Scope: RFC 7301 defines per-connection application-protocol negotiation for the TLS versions current when it was published. TLS 1.3 carries the server selection in EncryptedExtensions rather than ServerHello. ALPN selects a protocol; it does not authenticate an agent, authorize a task, or bind two separately terminated TLS connections.

Q1: Is this ClientHello ALPN list valid under RFC 7301?

Multiple Choice

A client sends three protocol identifiers: h2, an empty byte string, and http/1.1. The implementation proposes ignoring the empty entry and continuing.

**Explanation:** A: A server ignores an unrecognized non-empty protocol name, but an empty ProtocolName violates the encoding rule. B: RFC 7301 Section 3.1 defines identifiers as opaque, non-empty byte strings; empty strings MUST NOT be included and byte strings MUST NOT be truncated. C: Every identifier in ProtocolNameList is subject to the ProtocolName length constraint. D: ClientHello carries a list of candidates; the exactly-one rule applies to the server's selection response.

Q2: Which protocol should the server select?

Multiple Choice

The client advertises h2 then http/1.1. The server supports both and orders its own preference as http/1.1 then h2.

**Explanation:** A: Client order communicates client preference, but RFC 7301 gives final selection to the server. B: Different orders do not remove the common protocol set. C: Section 3.2 says the server SHOULD select its most highly preferred supported protocol that the client also advertised. D: The server's ALPN response MUST contain exactly one ProtocolName.

Q3: What is the required ALPN failure for this server?

Multiple Choice

A server processes ALPN, supports only http/1.1, and receives a ClientHello whose only advertised protocol is h2.

**Explanation:** A: A selected protocol has to come from the client's advertised list. B: RFC 7301 does not define a plaintext fallback after an empty intersection. C: A server response contains exactly one non-empty selection; an empty selection is not the failure encoding. D: Section 3.2 uses SHALL for the fatal alert when the server supports none of the protocols advertised by the client.

Q4: Which diagnosis is consistent with the trace?

Multiple Choice

A client offers h2 and http/1.1. TLS completes, but the client reports no negotiated ALPN value and the server returned no ALPN extension.

**Explanation:** A: SNI indicates a server name; it neither selects nor hides an application protocol. B: RFC 7301 Section 3.1 makes the server response optional. A server that does not return the extension has made no ALPN selection, even though TLS can complete. C: An ALPN selection cannot be implicit or outside the advertised list. D: Application fallback behavior must not be confused with an explicit ALPN selection.

Q5: Is the server behavior conformant?

Multiple Choice

The server returns an ALPN selection of h2, then sends HTTP/1.1 application data on the same TLS connection because its backend pool changed.

**Explanation:** A: The server selection is not advisory. B: Backend topology does not create an exception to the wire contract. C: RFC 7301 Section 3.2 says the selection SHALL be definitive and the server SHALL NOT select one protocol and then use another for application data. D: ALPN may facilitate routing based on the negotiated protocol; it requires that routing preserve the selected protocol.

Q6: Which ALPN value controls the resumed connection?

Multiple Choice

A previous session negotiated h2. During resumption, the new ClientHello offers only http/1.1, which the server supports.

**Explanation:** A: RFC 7301 does not establish ALPN as a session-ticket property. B: Section 3.1 says ALPN establishes a property only of the connection; on resumption, previous contents are irrelevant and the new handshake messages control. C: RFC 7301 shows ALPN in an abbreviated handshake. D: The server selects exactly one protocol for the current connection.

Q7: Which visibility conclusion is supportable?

Multiple Choice

A privacy review claims that using TLS 1.3 makes the complete ALPN exchange invisible to an ordinary on-path observer.

**Explanation:** A: TLS 1.3 does not by itself encrypt the ordinary ClientHello; mechanisms such as ECH address that separate exposure. B: RFC 7301 Section 5 warns about identifier leakage and describes ALPN as an externally visible marker. C: RFC 8446 Section 4.2 places ALPN in EncryptedExtensions, protecting the server's selected value after ServerHello. The ordinary ClientHello offer can still be observable. D: TLS 1.3 moves the ALPN server response out of ServerHello into EncryptedExtensions.

Q8: What may the backend conclude from the gateway's ALPN metadata?

Multiple Choice

An A2A gateway terminates a client TLS connection that selected h2. It opens a separate TLS connection to a backend and forwards a header saying external-alpn=h2. The backend proposes treating that header as proof of the original secure channel, agent identity, grant holder, and task authorization.

**Explanation:** A: ALPN is a property of one TLS connection; copying its text does not cryptographically bind another connection. B: RFC 7301 establishes neither agent identity nor possession of an authorization grant. C: Sections 3.1-3.2 define protocol negotiation per connection. The backend can trust gateway metadata only under its explicit gateway-to-backend trust model; A2A identity, credential, sender-binding, and authorization rules must establish the independent claims. D: RFC 7301 does not prohibit operational use of the selected value; it limits what that value means.