idnits 2.17.1 draft-thomson-tls-snip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 January 2021) is 1201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-39 -- Obsolete informational reference (is this intentional?): RFC 6555 (ref. 'HAPPY-EYEBALLS') (Obsoleted by RFC 8305) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-13 -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-33 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-33 -- Duplicate reference: RFC8446, mentioned in 'TLS', was also mentioned in 'RFC8446'. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational 4 January 2021 5 Expires: 8 July 2021 7 Secure Negotiation of Incompatible Protocols in TLS 8 draft-thomson-tls-snip-01 10 Abstract 12 An extension is defined for TLS that allows a client and server to 13 detect an attempt to force the use of less-preferred application 14 protocol even where protocol options are incompatible. This 15 supplements application-layer protocol negotiation, which allows 16 choices between compatible protocols to be authenticated. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the TLS Working Group 23 mailing list (tls@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/tls/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/martinthomson/snip. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 July 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Incompatible Protocols and SVCB . . . . . . . . . . . . . . . 4 65 4. Authenticating Incompatible Protocols . . . . . . . . . . . . 4 66 5. Incompatible Protocol Selection . . . . . . . . . . . . . . . 6 67 6. Protocol Authentication Scope . . . . . . . . . . . . . . . . 7 68 6.1. The Default Scope . . . . . . . . . . . . . . . . . . . . 8 69 6.2. SVCB Scope . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.3. QUIC Version Negotiation Scope . . . . . . . . . . . . . 8 71 7. Other Discovery Methods . . . . . . . . . . . . . . . . . . . 9 72 7.1. Alternative Services . . . . . . . . . . . . . . . . . . 9 73 8. Operational Considerations . . . . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 With increased diversity in protocol choice, some applications are 85 able to use one of several semantically-equivalent protocols to 86 achieve their goals. This is particularly notable in HTTP where 87 there are currently three distinct protocols: HTTP/1.1 [HTTP11], 88 HTTP/2 [HTTP2], and HTTP/3 [HTTP3]. This is also true of protocols 89 that support variants based on both TLS [TLS] and DTLS [DTLS]. 91 For protocols that are mutually compatible, Application-Layer 92 Protocol Negotiation (ALPN; [ALPN]) provides a secure way to 93 negotiate protocol selection. 95 In ALPN, the client offers a list of options in a TLS ClientHello and 96 the server chooses the option that it most prefers. A downgrade 97 attack occurs where both client and server support a protocol that 98 the server prefers more than than the selected protocol. ALPN 99 protects against this attack by ensuring that the server is aware of 100 all options the client supports and including those options and the 101 server choice under the integrity protection provided by the TLS 102 handshake. 104 This downgrade protection functions because protocol negotiation is 105 part of the TLS handshake. The introduction of semantically- 106 equivalent protocols that use incompatible handshakes introduces new 107 opportunities for downgrade attack. For instance, it is not possible 108 to negotiate the use of HTTP/2 based on an attempt to connect using 109 HTTP/3. The former relies on TCP, whereas the latter uses UDP. 110 These protocols are therefore mutually incompatible. 112 This document defines an extension to TLS that allows clients to 113 discover when servers support alternative protocols that are 114 incompatible with the currently-selected TLS version. This might be 115 used to avoid downgrade attack caused by interference in protocol 116 discovery mechanisms. 118 This extension is motivated by the addition of new mechanisms, such 119 as [SVCB]. SVCB enables the discovery of servers that support 120 multiple different protocols, some of which are incompatible. The 121 extension can also be used to authenticate protocol choices that are 122 discovered by other means. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 Two protocols are consider "compatible" if it is possible to 133 negotiate either using the same connection attempt. In comparison, 134 protocols are "incompatible" if they require separate attempts to 135 establish a connection. 137 3. Incompatible Protocols and SVCB 139 The SVCB record [SVCB] allows a client to learn about services 140 associated with a domain name. This includes how to locate a server, 141 along with supplementary information about the server, including 142 protocols that the server supports. This allows a client to start 143 using a protocol of their choice without added latency, as the lookup 144 can be performed concurrently with other name resolution. The added 145 cost of the additional DNS queries is minimal. 147 However, SVCB provides no protection against a downgrade attack 148 between incompatible protocols. An attacker could remove DNS records 149 for client-preferred protocols, leaving the client to believe that 150 only less-prefered, mutually-incompatible options are available. The 151 client only offers compatible options to a server in its TLS 152 handshake. Even if a client were to inform the server that it 153 supports a more preferred protocol, the server would not be able to 154 act upon it. 156 Authenticating all of the information presented in SVCB records might 157 provide clients with complete information about server support, but 158 this is impractical for several reasons: 160 * it is not possible to ensure that all server instances in a 161 deployment have the same protocol configuration, as deployments 162 for a single name routinely include multiple providers that cannot 163 coordinate closely; 165 * the ability to provide a subset of valid DNS records is integral 166 to many strategies for managing servers; and 168 * it is difficult to ensure that cached DNS records are synchronized 169 with server state. 171 Overall, an authenticated TLS handshake is a better source of 172 authoritative information about the protocols that are supported. 174 4. Authenticating Incompatible Protocols 176 The incompatible_protocols(TBD) TLS extension provides clients with 177 information about the incompatible protocols that are supported by 178 servers. 180 enum { 181 incompatible_protocols(TBD), (65535) 182 } ExtensionType; 183 A client that supports the extension advertises an empty extension. 184 In response, a server that supports this extension includes a list of 185 application protocol identifiers. The "extension_data" field of the 186 value server extension uses the "ProtocolName" type defined in 187 [ALPN], which is repeated here. This syntax is shown in Figure 1. 189 enum { 190 default(0), svcb(1), quic(2), (255) 191 } ProtocolAuthenticationScope; 193 opaque ProtocolName<1..2^8-1>; 195 struct { 196 ProtocolAuthenticationScope scope; 197 ProtocolName protocol; 198 } IncompatibleProtocol; 200 struct { 201 select (Handshake.msg_type) { 202 case client_hello: 203 Empty; 204 case encrypted_extensions: 205 IncompatibleProtocol incompatible_protocols<3..2^16-1>; 206 }; 207 } IncompatibleProtocols; 209 Figure 1: TLS Syntax for incompatible_protocols Extension 211 This extension only applies to the ClientHello and 212 EncryptedExtensions messages. An implementation that receives this 213 extension in any other handshake message MUST send a fatal 214 illegal_parameter alert. 216 A server deployment that supports multiple incompatible protocols MAY 217 advertise all protocols that are supported. Each protocol is paired 218 with an identifier for the Protocol Authentication Scope, which 219 defines how endpoints for that protocol might be discovered; see 220 Section 6. 222 A server needs to ensure that protocols advertised in this fashion 223 are available to the client within the same protocol authentication 224 scope. 226 A server MUST omit any compatible protocols from this extension. 227 That is, any protocol that the server might be able to select, had 228 the client offered the protocol in the 229 application_layer_protocol_negotiation extension. Clients are 230 expected to include all compatible protocols in the 231 application_layer_protocol_negotiation extension. 233 A server MAY limit the incompatible protocols that it advertises to 234 those that have similar semantics to protocols that the client lists 235 in its application_layer_protocol_negotiation extension. 237 The definition of what a server includes is intentionally flexible. 238 It is better that a server offer more information than less as the 239 needs of a client are not necessarily well reflected in its ALPN 240 extension. However, it might not be feasible for a server to 241 advertise all potential protocols; see Section 8 for more discussion 242 on this point. 244 5. Incompatible Protocol Selection 246 This document expands the definition of protocol negotiation to 247 include both compatible and incompatible protocols and provide 248 protection against downgrade for both types of selection. ALPN 249 [ALPN] only considers compatible protocols: the client presents a set 250 of compatible options and the server chooses its most preferred. 252 With an selection of protocols that includes incompatible options, 253 the client makes a selection between incompatible options before 254 making a connection attempt. Therefore, this design does not enable 255 negotiation, it instead provides the client with information about 256 other incompatible protocols that the server might support. 258 Detecting a potential downgrade between incompatible protocols does 259 not automatically imply that a client abandon a connection attempt. 260 It only provides the client with authenticated information about its 261 options. What a client does with this information is left to client 262 policy. 264 In brief: 266 * For compatible protocols, the client offers all acceptable options 267 and the server selects its most preferred 269 * For incompatible protocols, information the server offers is 270 authenticated and the client is able to act on that 272 For a protocol like HTTP/3, this might not result in the client 273 choosing to use HTTP/3, even if HTTP/3 is preferred and the server 274 indicates that a service endpoint supporting HTTP/3 is available. 275 Blocking of UDP or QUIC is known to be widespread. As a result, 276 clients might adopt a policy of tolerating a downgrade to a TCP-based 277 protocol, even if HTTP/3 were preferred. However, as blocking of UDP 278 is highly correlated by access network, clients that are able to 279 establish HTTP/3 connections to some servers might choose to apply a 280 stricter policy when a server that indicates HTTP/3 support is 281 unreachable. 283 6. Protocol Authentication Scope 285 A protocol authentication scope includes a set of service endpoints 286 that are provided downgrade protection by this mechanism. There are 287 multiple types of protocol authentication scope, each identified by a 288 different type. The type of protocol authentication scope is encoded 289 in the "ProtocolAuthenticationScope" enum. 291 The type of protocol authentication scope describes how a client 292 might learn of all of the service endpoints that a server offers in 293 that scope. If a client has attempted to discover service endpoints 294 using the methods defined by the protocol authentication scope, 295 receiving an incompatible_protocols extension from a server is a 296 strong indication of a potential downgrade attack. 298 A client considers that a downgrade attack might have occurred if all 299 of the following occur: 301 1. A server advertises that there are endpoints that support a 302 protocol that the client prefers over the protocol that is 303 currently in use. 305 2. The protocol authentication scope associated with that protocol 306 is understood by the client and the client attempted to discover 307 services in that scope. 309 In response to detecting a potential downgrade attack, a client might 310 abandon the current connection attempt and report an error. A client 311 that supports discovery of incompatible protocols, but chooses not to 312 make a discovery attempt under normal conditions might instead not 313 fail, but it could use what it learns as cause to initiate discovery. 315 6.1. The Default Scope 317 The default protocol authentication scope reserves an identifier of 318 0. A client cannot act on information about incompatible protocols 319 advertised with this scope. A server MUST NOT advertise incompatible 320 protocols with this scope; however, a client MUST ignore 321 advertisements it receives. 323 The default protocol authentication scope is reserved for discovery 324 methods that have no explicit scope; see Section 7 for more on this 325 subject. 327 6.2. SVCB Scope 329 The SVCB protocol authentication scope uses an identifier of 1. A 330 server that lists incompatible protocols with this scope indicates 331 that SVCB records ServiceForm records with the same SvcDomainName 332 exist that refer to services that support the indicated protocol. 334 The SVCB protocol authentication scope also applies to records that 335 use the SVCB form, like HTTPS. 337 This ensures that the final choice a client makes between ServiceForm 338 SVCB records is protected by this extension. If the client does not 339 receive a SVCB record for a protocol that the server includes in its 340 incompatible_protocols extension, then it can assume that this 341 omission was caused by an error or attack. 343 A choice between AliasForm records (or CNAME or DNAME records) is not 344 authenticated, but choices between ServiceForm records is. This 345 allows for server deployments for the same name to have different 346 administrative control and protocol configurations. 348 6.3. QUIC Version Negotiation Scope 350 The QUIC version negotiation protocol authentication scope uses an 351 identifier of 2. A server that lists incompatible protocols with 352 this scope indicates that QUIC version negotiation at the same server 353 IP and port could be used to learn of incompatible QUIC versions that 354 support the indicated protocol. 356 Using this protocol authentication scope depends on application 357 protocols that are dependent on a specific QUIC version. 359 7. Other Discovery Methods 361 For other discovery methods, a definition for protocol authentication 362 scope is needed before a client can act on what is learned using the 363 incompatible_protocols extension. That definition needs to define 364 how to discover server instances that support all incompatible 365 protocols in the scope. 367 In particular, a server that is discovered using forms of DNS-based 368 name resolution other than SVCB uses the default protocol 369 authentication scope; see Section 6.1. Discovering services in this 370 way does not provide enough information to locate other incompatible 371 protocols. 373 For instance, an HTTPS server that is discovered using purely A or 374 AAAA records (and CNAME or DNAME records) might advertise support for 375 incompatible protocols, but as there is no way to determine where 376 those protocols are supported, a client cannot act on the 377 information. Note that Alternative Services do not change the 378 protocol authentication scope. 380 Deployments of discovery methods that define a protocol 381 authentication scope larger than the default need to ensure that 382 every server provides information that is consistent with every 383 protocol authentication scope that includes that server. A server 384 that fails to indicate support for a protocol that is within a 385 protocol authentication scope does not offer any protection against 386 attack; a server that advertises a protocol that the client cannot 387 discover risks this misconfiguration being identified as an attack by 388 clients. 390 7.1. Alternative Services 392 It is possible to negotiate protocols based on an established 393 connection without exposure to downgrade. The Alternative Services 394 [ALTSVC] bootstrapping in HTTP/3 [HTTP3] does just that. Assuming 395 that HTTP/2 or HTTP/1.1 are not vulnerable to attacks that would 396 compromise integrity, a server can advertise the presence of an 397 endpoint that supports HTTP/3. 399 Under these assumptions Alternative Services is secure, but it has 400 performance trade-offs. A client could attempt the protocol it 401 prefers most, but that comes at a risk that this protocol is not 402 supported by a server. A client could implement a fallback, which 403 might even be performed concurrently (see [HAPPY-EYEBALLS]), but this 404 costs time and resources. A client avoids these costs by attempting 405 the protocol it believes to be most widely supported, though this 406 comes with a performance penalty in cases where the most-preferred 407 protocol is supported. 409 A server that is discovered using Alternative Services uses the 410 default protocol authentication scope. As use of Alternative 411 Services is discretionary for both client and server, a client cannot 412 expect to receive information about incompatible protocols. To avoid 413 downgrade, a client only has to limit its use of Alternative Services 414 to those that it prefers more than the active protocol. 416 8. Operational Considerations 418 By listing incompatible protocols, a server does not indicate how to 419 find endpoints that support those protocols, only that they exist. 420 This ensures that server configuration is minimized, as servers do 421 not require tight coordination. Providing even this much information 422 could present operational difficulties as it requires that 423 incompatible protocols are only listed when those protocols are 424 deployed. 426 Server deployments can choose not to provide information about 427 incompatible protocols, which denies clients information about 428 downgrade attacks but might avoid the operational complexity of 429 providing accurate information. 431 During rollout of a new, incompatible protocol, until the deployment 432 is stable and not at risk of being disabled, servers SHOULD NOT 433 advertise the existence of the new protocol. Protocol deployments 434 that are disabled, first need to be removed from the 435 incompatible_protocols extension or there could be some loss of 436 service. Though the incompatible_protocols extension only applies at 437 the time of the TLS handshake, clients might take some time to act on 438 the information. If an incompatible protocol is removed from 439 deployment between when the client completes a handshake and when it 440 acts, this could be treated as an error by the client. 442 If a server does not list available, incompatible protocols, clients 443 cannot learn about other services and so cannot detect downgrade 444 attacks against those protocols. 446 9. Security Considerations 448 This design depends on the integrity of the TLS handshake across all 449 forms, including TLS [RFC8446], DTLS [DTLS], and QUIC [QUIC-TLS]. An 450 attacker that can modify a TLS handshake in any one of these 451 protocols can cause a client to believe that other options do not 452 exist. 454 A server deployment that uses AliasForm SVCB records and does not 455 uniformly support a client-preferred protocol is vulnerable to 456 downgrade attacks that steer clients toward instances that lack 457 support for that protocol. This attack is ineffective for protocols 458 that are consistently supported by all server instances. 460 10. IANA Considerations 462 TODO: register the extension 464 TODO: create a registry of scopes 466 11. References 468 11.1. Normative References 470 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 471 "Transport Layer Security (TLS) Application-Layer Protocol 472 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 473 July 2014, . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 481 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 482 May 2017, . 484 11.2. Informative References 486 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 487 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 488 April 2016, . 490 [DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 491 Datagram Transport Layer Security (DTLS) Protocol Version 492 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 493 dtls13-39, 2 November 2020, . 496 [HAPPY-EYEBALLS] 497 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 498 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 499 2012, . 501 [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1", 502 Work in Progress, Internet-Draft, draft-ietf-httpbis- 503 messaging-13, 14 December 2020, . 506 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 507 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 508 DOI 10.17487/RFC7540, May 2015, 509 . 511 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 512 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 513 quic-http-33, 15 December 2020, . 516 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 517 Work in Progress, Internet-Draft, draft-ietf-quic-tls-33, 518 13 December 2020, . 521 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 522 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 523 . 525 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 526 and parameter specification via the DNS (DNS SVCB and 527 HTTPSSVC)", Work in Progress, Internet-Draft, draft-ietf- 528 dnsop-svcb-httpssvc-03, 11 June 2020, 529 . 532 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 533 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 534 . 536 Appendix A. Acknowledgments 538 Benjamin Schwartz provided significant input into the design of the 539 mechanism and helped clarify many points. 541 Author's Address 543 Martin Thomson 544 Mozilla 546 Email: mt@lowentropy.net