Skip to main content

Secure Negotiation of Incompatible Protocols in TLS
draft-ietf-tls-snip-02

Document Type Active Internet-Draft (tls WG)
Author Martin Thomson
Last updated 2022-06-30
Replaces draft-thomson-tls-snip
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-tls-snip-02
Network Working Group                                         M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Informational                              30 June 2022
Expires: 1 January 2023

          Secure Negotiation of Incompatible Protocols in TLS
                         draft-ietf-tls-snip-02

Abstract

   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.

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 1 January 2023.

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.

Thomson                  Expires 1 January 2023                 [Page 1]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Incompatible Protocol Selection . . . . . . . . . . . . . . .   4
     3.1.  Client Policy . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Logical Servers . . . . . . . . . . . . . . . . . . . . .   4
   4.  Authenticating Incompatible Protocols . . . . . . . . . . . .   5
     4.1.  Validation  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  QUIC Version Negotiation  . . . . . . . . . . . . . . . .   7
     4.3.  HTTP Alternative Services . . . . . . . . . . . . . . . .   7
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11
   Appendix B.  Defining Logical Servers . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

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

Thomson                  Expires 1 January 2023                 [Page 2]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

   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 [QUIC] 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 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.

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.

Thomson                  Expires 1 January 2023                 [Page 3]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

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 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
   Section 3.2).  How clients use this information will depend on client
   policy.

3.1.  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 [SVCB].

   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.

3.2.  Logical Servers

   This document relies on the notion of a logical server for
   determining how a client interprets information about incompatible
   protocols.

Thomson                  Expires 1 January 2023                 [Page 4]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

   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 Section 5.

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;

         Figure 1: TLS Syntax for incompatible_protocols Extension

Thomson                  Expires 1 January 2023                 [Page 5]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

   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.

4.1.  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,

Thomson                  Expires 1 January 2023                 [Page 6]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

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

4.2.  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 [QUIC-VN] 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.

4.3.  HTTP Alternative Services

   It is possible to select incompatible protocols based on an
   established connection.  The Alternative Services [ALTSVC]
   bootstrapping in HTTP/3 [HTTP3] 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.

Thomson                  Expires 1 January 2023                 [Page 7]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

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:

Thomson                  Expires 1 January 2023                 [Page 8]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

   Value:  TBD

   Extension Name:  incompatible_protocols

   TLS 1.3:  CH, EE

   DTLS-Only:  N

   Recommended:  Y

   Reference:  this document, Section 4

8.  References

8.1.  Normative References

   [ALPN]     Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

   [ALTSVC]   Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [BCP126]   Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006.

              <https://www.rfc-editor.org/info/bcp126>

   [DTLS]     Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
              dtls13-43, 30 April 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              dtls13-43>.

Thomson                  Expires 1 January 2023                 [Page 9]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

   [HTTP11]   Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

   [HTTP2]    Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.

   [HTTP3]    Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
              Work in Progress, Internet-Draft, draft-ietf-quic-tls-34,
              14 January 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-quic-tls-34>.

   [QUIC-VN]  Schinazi, D. and E. Rescorla, "Compatible Version
              Negotiation for QUIC", Work in Progress, Internet-Draft,
              draft-ietf-quic-version-negotiation-08, 8 June 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
              version-negotiation-08>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [SVCB]     Schwartz, B., Bishop, M., and E. Nygren, "Service binding
              and parameter specification via the DNS (DNS SVCB and
              HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
              dnsop-svcb-https-10, 24 May 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              svcb-https-10>.

   [TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

Thomson                  Expires 1 January 2023                [Page 10]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

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 (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 [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.

Thomson                  Expires 1 January 2023                [Page 11]
Internet-Draft    Authenticating Incompatible Protocols        June 2022

   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.

Author's Address

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net

Thomson                  Expires 1 January 2023                [Page 12]