Secure Negotiation of Incompatible Protocols in TLS

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 August 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [HTTP11], HTTP/2 [HTTP2], and HTTP/3 [HTTP3]. This is also true of protocols that support variants based on both TLS [TLS] and DTLS [DTLS].¶

For protocols that are mutually compatible, Application-Layer Protocol Negotiation (ALPN; [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 server is aware of all options the client supports and including those options and the server choice under the integrity protection provided by the TLS handshake.¶

Downgrade protection in ALPN functions because protocol negotiation is part of the TLS handshake. The introduction of semantically-equivalent protocols that use incompatible handshakes introduces new opportunities for downgrade attack. 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. These protocols are therefore mutually incompatible and ALPN cannot be used to securely select between the two.¶

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 Section 3.2). 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 [HTTP3] 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 [ALTSVC] is included in Section 4.3 and a discussion of SVCB [SVCB] can be found in Appendix C.¶

2. 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 [RFC2119] [RFC8174] 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.¶

3. Incompatible Protocol Selection

This document extends the authentication protections provided by TLS to cover negotiation of incompatible protocols.¶

This is complementary to ALPN [ALPN], which only protects the negotiation of compatible protocols. In ALPN, the client presents a set of compatible options and the server chooses its most preferred.¶

This extension works by having a server offer a list of incompatible protocols that it supports on the same logical server (see Section 3.2). How clients use this information will depend on client policy.¶

4. 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 Section 3.2 for a definition of a logical server.¶

enum {
    incompatible_protocols(TBD), (65535)
} ExtensionType;

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 [ALPN]. This syntax is shown in Figure 1.¶

opaque ProtocolName<1..2^8-1>;  // 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.¶

A client offers an empty extension to indicate that is 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 MUST 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.¶

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.¶

5. 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 [BCP126] 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.¶

6. Security Considerations

This design depends on the integrity of the TLS handshake across all forms, including TLS [RFC8446], DTLS [DTLS], and QUIC [QUIC-TLS]. 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.¶

7. 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, Section 4¶

Appendix A. Acknowledgments

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

Appendix B. 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:¶

• 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 [URI], which is in effect domain name plus port number.¶
• The set of endpoints that are referenced by the same SVCB ServiceMode record; see Section 2.4.3 of [SVCB].¶
• 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 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. Finally, 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.¶

Appendix C. Incompatible Protocols and SVCB

The SVCB record [SVCB] allows a client to learn about services associated with a domain name. This includes how to locate a server, along with supplementary information about the server, including protocols that the server supports. This allows a client to start using a protocol of their choice without added latency, as a query for SVCB records can be performed at the same time as name resolution.¶

However, SVCB provides no protection against a downgrade attack between incompatible protocols. An attacker could remove DNS records for protocols that the client prefers, leaving the client to believe that only less-preferred options are available. If removed options are not compatible with the option that is chosen, the client will attempt those less-preferred options when attempting a TLS handshake.¶

Authenticating all of the information presented in SVCB records might provide clients with complete information about server support, but this is impractical for several reasons:¶

• it is not possible to ensure that all server instances in a deployment have the same protocol configuration, as deployments for a single name routinely include multiple providers that cannot coordinate closely;¶
• the ability to provide a subset of valid DNS records is integral to many strategies for managing servers; and¶
• ensuring that cached DNS records are synchronized with server state is challenging in a number of deployments.¶

Overall, an authenticated TLS handshake is a better source of authoritative information.¶

Author's Address