]> Mozilla

mt@lowentropy.net

An extension is defined for TLS that allows a client and server to detect an attempt to force the use of less-preferred application protocol even where protocol options are incompatible. This supplements application-layer protocol negotiation (ALPN), which allows choices between compatible protocols to be authenticated.

Introduction With increased diversity in protocol choice, some applications are able to use one of several semantically-equivalent protocols to achieve their goals. This is particularly notable in HTTP where there are currently three distinct protocols: HTTP/1.1 , HTTP/2 , and HTTP/3 . This is also true of protocols that support variants based on both TLS and DTLS . For protocols that are mutually compatible, Application-Layer Protocol Negotiation (ALPN; ) provides a secure way to negotiate protocol selection. In ALPN, the client offers a list of options in a TLS ClientHello and the server chooses the option that it most prefers. A downgrade attack occurs where both client and server support a protocol that the server prefers more than than the selected protocol. ALPN protects against this attack by ensuring that the options the client offers and the choice the server makes are included in the TLS handshake. Confirming the TLS handshake then ensures that the client and server agree on both the offered options and the server choice, preventing an attacker from altering either. The introduction of semantically-equivalent protocols that use incompatible handshakes introduces new opportunities for downgrade attack. ALPN cannot be used to securely select between incompatible protocols. For instance, it is not possible to negotiate the use of HTTP/2 based on an attempt to connect using HTTP/3. The former relies on TCP, whereas the latter uses UDP. In this example, a client that attempts a connection with HTTP/2 cannot use ALPN to express that it might want to use HTTP/3. The client needs to initiate a QUIC connection if it wants to attempt HTTP/3. Even if HTTP/3 is preferred, an attacker need only block the HTTP/3 connection attempt to cause the client and server to use HTTP/2. This document defines an extension to TLS that allows clients to discover when a server supports alternative protocols that are incompatible with the protocol in use. This might be used to detect a downgrade attack. Downgrade protection for incompatible protocols only works for services provided by the same logical server (see ). That is, the protection only applies to servers that operate from the same IP address and port number from the perspective of the client. This extension is motivated by the addition of new protocols such as HTTP/3 that are semantically equivalent, but incompatible with existing protocols. These downgrade protections are intended to work for any method that a client might use to discover that a server supports a particular protocol. Special considerations for HTTP Alternative Services is included in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Two protocols are considered "compatible" if it is possible to negotiate either using the same connection attempt. In comparison, protocols are "incompatible" if they require separate attempts to establish a connection.

Incompatible Protocol Selection This document extends the authentication protections provided by TLS to cover negotiation of incompatible protocols. This is complementary to ALPN , which protects the negotiation of compatible protocols. In ALPN, the client presents a set of compatible options and the server chooses its most preferred and the server chooses its most preferred. This extension works by having a server offer a list of incompatible protocols that are available for use on the same logical server (see ). How clients use this information will depend on client policy.

Client Policy A client has to choose between incompatible options before making a connection attempt. Thefore, this document does not define a negotiation mechanism, it only provides authenticated information that a client can use to validate information it acquires from other sources, such as . Importantly, detecting a potential downgrade between incompatible protocols does not automatically imply that a client abandon a connection attempt. It only provides the client with authenticated information that can help with making a decision. What a client does with this information is left to client policy. For a protocol like HTTP/3, this might not result in the client choosing to use HTTP/3, even if HTTP/3 is preferred and the server indicates that a service endpoint supporting HTTP/3 is available. Blocking of UDP or QUIC is known to be widespread. As a result, clients might adopt a policy of tolerating a downgrade to a TCP-based version of HTTP, even if HTTP/3 were preferred. However, as blocking of UDP is highly correlated by access network, clients that are able to establish HTTP/3 connections to some servers might choose to apply a stricter policy when a server that indicates HTTP/3 support is unreachable.

Logical Servers This document relies on the notion of a logical server for determining how a client interprets information about incompatible protocols. Clients can assume availability of incompatible protocols across the set of endpoints that share an IP version, IP address, and port number with the TLS server that provides the incompatible_protocols extension. This definition includes a port number that is independent of the protocol that is used. Any protocol that defines a port number is considered to be equivalent. In particular, incompatible protocols can be deployed to TCP, UDP, SCTP, or DCCP ports as long as the IP address and port number is the same. This determination is made from the perspective of a client. This means that server operators need to be aware of all instances that might answer to the same IP address and port; see .

Authenticating Incompatible Protocols The incompatible_protocols(TBD) TLS extension provides clients with information about the incompatible protocols that are supported by the same logical server; see for a definition of a logical server. A client that supports the extension advertises an empty extension. In response, a server that supports this extension includes a list of application protocol identifiers. The "extension_data" field of the server extension uses the ProtocolName type defined in . This syntax is shown in .

TLS Syntax for incompatible_protocols Extension ; // From RFC 7301 ProtocolName IncompatibleProtocol; struct { select (Handshake.msg_type) { case client_hello: Empty; case encrypted_extensions: IncompatibleProtocol incompatible_protocols<3..2^16-1>; }; } IncompatibleProtocols; ]]>

This extension only applies to the ClientHello and EncryptedExtensions messages. An implementation that receives this extension in any other handshake message MUST send a fatal illegal_parameter alert. Clients and servers MUST include the application_layer_protocol_negotiation extension if they include an incompatible_protocols extension. An endpoint that receives an incompatible_protocols extension without an application_layer_protocol_negotiation extension MUST send a fatal missing_extension alert. A client offers an empty extension to indicate that it wishes to receive information about incompatible protocols supported by the (logical) server. A server deployment that supports multiple incompatible protocols MAY advertise all protocols that are supported by the same logical server. A server needs to ensure that protocols advertised in this fashion are available to the client. A server SHOULD omit any compatible protocols from this extension. That is, any protocol that the server might be able to select, had the client offered the protocol in the application_layer_protocol_negotiation extension. In comparison, clients are expected to include all compatible protocols in the application_layer_protocol_negotiation extension. This recommendation exists only so that implementations choose a consistent - and smaller - encoding; clients MUST NOT abort a handshake if the server lists a compatible protocol. Information presented by the server is only valid at the time it is provided. A client can act on that information immediately, but it cannot retain the information on the expectation that it will be valid later. A server therefore only needs to consider providing information that is current for a period that would allow the client to act, which might amount to a few seconds.

Validation A client detects a likely downgrade attack if:

• the client has discovered server endpoints for a preferred protocol that point to a logical server,
• an attempt to connect using the preferred protocol is unsuccessful,
• an attempt to connect to the same logical server using a protocol that is incompatible with the preferred protocol is successful, and
• an incompatible_protocols extension that lists the preferred protocol is received on the successful connection attempt.

In response to detecting a potential downgrade attack, a client might abandon the current connection attempt and report an error. These steps can occur in a different order. For instance, a client might support an incompatible protocol, but choose not to attempt to make a connection with that protocol under normal conditions. That client might instead make a connection attempt or initiate discovery for that protocol when it learns that the preferred protocol is available by some means. Such a client then detects a downgrade attack when the connection attempt fails.

QUIC Version Negotiation QUIC enables the definition of incompatible protocols that share a port. The incompatible_protocols extension can be used to authenticate the choice of application protocols across incompatible QUIC version. QUIC version negotiation is used to authenticate the choice of QUIC version. As there are two potentially competing sets of preferences at different protocol layers, clients need to set preferences for QUIC version and application protocol are consistent. For example, if application protocol A exclusively uses QUIC version X and application protocol B exclusively uses QUIC version Y, setting a preference for both A and Y will result in one or other option not being selected. This would result in failure if the client applied a policy that regarded either downgrade as an error.

HTTP Alternative Services It is possible to select incompatible protocols based on an established connection. The Alternative Services bootstrapping in HTTP/3 is not vulnerable to downgrade as the signal is exchanged over an authenticated connection. A server can advertise the presence of an endpoint that supports HTTP/3 using an HTTP/2 or HTTP/1.1 connection. A client MAY choose to ignore incompatible protocols when attempting to use an alternative service.

Operational Considerations By listing incompatible protocols a server needs to be certain that the incompatible protocols are available. Ensuring that this information is correct might need some amount of coordination in server deployments. In particular, coordination is important if a load balancer distributes load for a single IP address to multiple server instances, or where anycast is used. Incompatible protocols can only be listed in the incompatible_protocols extension when those protocols are deployed across all server instances. A client might regard lack of availability for an advertised protocol as a downgrade attack, which could lead to service outages for those clients. Server deployments can choose not to provide information about incompatible protocols might avoid the operational complexity of providing accurate information. If a server does not list incompatible protocols, clients cannot gain authenticated information about their availability and so cannot detect downgrade attacks against those protocols. During rollout of a new, incompatible protocol, until the deployment is stable and not at risk of being disabled, servers SHOULD NOT advertise the existence of the new protocol. Protocol deployments that are in the process of being disabled first need to be removed from the incompatible_protocols extension. If a disabled protocol is advertised to clients, clients might regard this as a downgrade attack. Though the incompatible_protocols extension only applies at the time of the TLS handshake, clients might take some time to act on the information. If an incompatible protocol is removed from deployment between when the client completes a handshake and when it acts, this could be treated as an error by the client.

Security Considerations This design depends on the integrity of the TLS handshake across all forms, including TLS , DTLS , and QUIC . Similarly, integrity is necessary across all TLS versions that a client is willing to negotiate. An attacker that can modify a TLS handshake in any one of these protocols or versions can cause a client to believe that other options do not exist.

IANA Considerations IANA is requested to assign a new value from the "TLS ExtensionType Values" registry:

Value:

TBD

Extension Name:

incompatible_protocols

TLS 1.3:

CH, EE

DTLS-Only:

N

Recommended:

Y

Reference:

this document,

References Normative References This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Google Akamai Technologies Akamai Technologies This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. RTFM, Inc. Arm Limited Google, Inc. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Google LLC Mozilla QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Mozilla sn3rd This document describes how Transport Layer Security (TLS) is used to secure QUIC. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

Acknowledgments Benjamin Schwartz provided significant input into the design of the mechanism and helped simplify the overall design.

Defining Logical Servers As incompatible protocols use different protocol stacks, they also use different endpoints. In other words, it is impossible for a single endpoint to support multiple incompatible protocols. Thus, it is necessary to understand the set of endpoints at a server that offer the incompatible protocols. Thus, the definition of where incompatible protocols needs to encompass multiple endpoints somehow. A number of choices are possible here (this list is not exhaustive):

• The set of endpoints that are authoritative for the same domain name.
• The set of endpoints that are authoritative for the same "authority" as defined in RFC 3986 , which is in effect domain name plus port number.
• The set of endpoints that are referenced by the same SVCB ServiceMode record; see .
• The set of endpoints that share an IP address.
• The set of endpoints that share an IP address and port number.

The challenge with options based on domain name is that it might prevent the use of multiple service providers. This is a common practice for HTTP, where the same domain name can be operated by multiple CDN operators. Having multiple service operators also rules out using SVCB ServiceMode records also as different records might be used to identify different operators. Hosts on the same IP address might work, but common deployment practices include use of different ports for entirely different services. These can have different operational constraints, such as deployment schedules. Including different ports in the same scope could force all services on the same host to support a consistent set of protocols. This leaves IP and port. There is still a risk that the same port number is used for completely different purposes depending on the choice of protocol. This practice is sufficiently rare that it is not anticipated to be a problem. A deployment with no ability to coordinate the deployment of protocols that share an IP and port can choose not to advertise the availability of incompatible protocols.