idnits 2.17.1 draft-thomson-tls-snip-00.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 (13 July 2020) is 1384 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-38 -- 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-10 -- 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-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 -- 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 13 July 2020 5 Expires: 14 January 2021 7 Secure Negotiation of Incompatible Protocols in TLS 8 draft-thomson-tls-snip-00 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 14 January 2021. 46 Copyright Notice 48 Copyright (c) 2020 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. Protocol Authentication Scope . . . . . . . . . . . . . . . . 5 67 5.1. SVCB Discovery Scope . . . . . . . . . . . . . . . . . . 6 68 5.2. QUIC Version Negotiation . . . . . . . . . . . . . . . . 6 69 5.3. Alternative Services . . . . . . . . . . . . . . . . . . 6 70 5.4. Scope for Other Discovery Methods . . . . . . . . . . . . 7 71 6. Incompatible Protocol Selection . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 With increased diversity in protocol choice, some applications are 83 able to use one of several semantically-equivalent protocols to 84 achieve their goals. This is particularly notable in HTTP where 85 there are currently three distinct protocols: HTTP/1.1 [HTTP11], 86 HTTP/2 [HTTP2], and HTTP/3 [HTTP3]. This is also true for protocols 87 that support variants based on both TLS [TLS] and DTLS [DTLS]. 89 For protocols that are mutually compatible, Application-Layer 90 Protocol Negotiation (ALPN; [ALPN]) provides a secure way to 91 negotiate protocol selection. 93 In ALPN, the client offers a list of options in a TLS ClientHello and 94 the server chooses the option that it most prefers. A downgrade 95 attack occurs where both client and server support a protocol that 96 the server prefers more than than the selected protocol. ALPN 97 protects against this attack by ensuring that the server is aware of 98 all options the client supports and including those options and the 99 server choice under the integrity protection provided by the TLS 100 handshake. 102 This downgrade protection functions because protocol negotiation is 103 part of the TLS handshake. The introduction of semantically- 104 equivalent protocols that use incompatible handshakes introduces new 105 opportunities for downgrade attack. For instance, it is not possible 106 to negotiate the use of HTTP/2 based on an attempt to connect using 107 HTTP/3. The former relies on TCP, whereas the latter uses UDP. 108 These protocols are therefore mutually incompatible. 110 This document defines an extension to TLS that allows clients to 111 discover when servers support alternative protocols that are 112 incompatible with the currently-selected TLS version. This might be 113 used to avoid downgrade attack caused by interference in protocol 114 discovery mechanisms. 116 This extension is motivated by the addition of new mechanisms, such 117 as [SVCB]. SVCB enables the discovery of servers that support 118 multiple different protocols, some of which are incompatible. The 119 extension can also be used to authenticate protocol choices that are 120 discovered by other means. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 Two protocols are consider "compatible" if it is possible to 131 negotiate either using the same connection attempt. In comparison, 132 protocols are "incompatible" if they require separate attempts to 133 establish a connection. 135 3. Incompatible Protocols and SVCB 137 The SVCB record [SVCB] allows a client to learn about services 138 associated with a domain name. This includes how to locate a server, 139 along with supplementary information about the server, including 140 protocols that the server supports. This allows a client to start 141 using a protocol of their choice without added latency, as the lookup 142 can be performed concurrently with other name resolution. The added 143 cost of the additional DNS queries is minimal. 145 However, SVCB provides no protection against a downgrade attack 146 between incompatible protocols. An attacker could remove DNS records 147 for client-preferred protocols, leaving the client to believe that 148 only less-prefered, mutually-incompatible options are available. The 149 client only offers compatible options to a server in its TLS 150 handshake. Even if a client were to inform the server that it 151 supports a more preferred protocol, the server would not be able to 152 act upon it. 154 Authenticating all of the information presented in SVCB records might 155 provide clients with complete information about server support, but 156 this is impractical for several reasons: 158 * it is not possible to ensure that all server instances in a 159 deployment have the same protocol configuration, as deployments 160 for a single name routinely include multiple providers that cannot 161 coordinate closely; 163 * the ability to provide a subset of valid DNS records is integral 164 to many strategies for managing servers; and 166 * it is difficult to ensure that cached DNS records are synchronized 167 with server state. 169 Overall, an authenticated TLS handshake is a better source of 170 authoritative information about the protocols that are supported. 172 4. Authenticating Incompatible Protocols 174 The incompatible_protocols(TBD) TLS extension provides clients with 175 information about the incompatible protocols that are supported by 176 servers. 178 enum { 179 incompatible_protocols(TBD), (65535) 180 } ExtensionType; 181 A client that supports the extension advertises an empty extension. 182 In response, a server that supports this extension includes a list of 183 application protocol identifiers. The "extension_data" field of the 184 value server extension uses the "ProtocolNameList" format defined in 185 [ALPN]. This syntax is shown in Figure 1. 187 struct { 188 select (Handshake.msg_type) { 189 case client_hello: 190 Empty; 191 case encrypted_extensions: 192 ProtocolNameList incompatible_protocols; 193 }; 194 } IncompatibleProtocols; 196 Figure 1: TLS Syntax for incompatible_protocols Extension 198 This extension only applies to the ClientHello and 199 EncryptedExtensions messages. An implementation that receives this 200 extension in any other handshake message MUST send a fatal 201 illegal_parameter alert. 203 A server deployment that supports multiple incompatible protocols MAY 204 advertise all protocols that are supported. A server MAY limit this 205 to protocols that it considers to have similar semantics to protocols 206 that the client lists in its application_layer_protocol_negotiation 207 extension. 209 The definition of what a server includes is intentionally loose. It 210 is better that a server offer more information than less as the needs 211 of a client are not necessarily well reflected in its ALPN extension. 212 However, it is not reasonable to require that a server advertise all 213 potential protocols as that is unlikely to be practical. 215 A server MUST omit any compatible protocols from this extension on 216 the understanding that the client will include compatible protocols 217 in the application_layer_protocol_negotiation extension. 219 A server needs to ensure that protocols advertised in this fashion 220 are available to the client within the same protocol authentication 221 scope. 223 5. Protocol Authentication Scope 225 The protocol authentication scope is the set of protocol endpoints at 226 a server that share a protocol configuration. A client learns of 227 this scope as part of the process it follows to discover the server. 229 By default, the protocol authentication scope is a single protocol 230 endpoint. The default protocol authentication scope offers no means 231 to authenticate incompatible protocols as it is not possible for a 232 client to access any endpoint that supports those protocols. A 233 client cannot use information from the incompatible_protocols 234 extension unless a wider scope is used. 236 [[TODO: This likely needs some discussion.]] 238 5.1. SVCB Discovery Scope 240 For SVCB records, the protocol authentication scope is defined by the 241 set of ServiceForm SVCB records with the same SvcDomainName. 243 This ensures that the final choice a client makes between ServiceForm 244 SVCB records is protected by this extension. If the client does not 245 receive a SVCB record for a protocol that the server includes in its 246 incompatible_protocols extension, then it can assume that this 247 omission was caused by an error or attack. 249 Thus, for SVCB, a choice between AliasForm records (or CNAME or DNAME 250 records) is not authenticated, but choices between ServiceForm 251 records is. This allows for server deployments for the same name to 252 have different administrative control and protocol configurations. 254 5.2. QUIC Version Negotiation 256 TODO: define how this can be used to authenticate protocol choices 257 where there are incompatible QUIC versions. 259 5.3. Alternative Services 261 It is possible to negotiate protocols based on an established 262 connection without exposure to downgrade. The Alternative Services 263 [ALTSVC] bootstrapping in HTTP/3 does just that. Assuming that 264 HTTP/2 or HTTP/1.1 are not vulnerable to attacks that would 265 compromise integrity, a server can advertise the presence of an 266 endpoint that supports HTTP/3. 268 Under these assumptions Alternative Services is secure, but it has 269 performance trade-offs. A client could attempt the protocol it 270 prefers most, but that comes at a risk that this protocol is not 271 supported by a server. A client could implement a fallback, which 272 might even be performed concurrently (see [HAPPY-EYEBALLS]), but this 273 costs time and resources. A client avoids these costs by attempting 274 the protocol it believes to be most widely supported, though this 275 comes with a performance penalty in cases where the most-preferred 276 protocol is supported. 278 A server that is discovered using Alternative Services uses the 279 default protocol authentication scope. As use of Alternative 280 Services is discretionary for both client and server, a client cannot 281 expect to receive information about incompatible protocols. To avoid 282 downgrade, a client only has to avoid using an Alternative Service 283 that offers a less-preferred protocol. 285 5.4. Scope for Other Discovery Methods 287 For other discovery methods, a definition for protocol authentication 288 scope is needed before a client can act on what is learned using the 289 incompatible_protocols extension. That definition needs to define 290 how to discover server instances that support all incompatible 291 protocols in the scope. 293 In particular, a server that is discovered using forms of DNS-based 294 name resolution other than SVCB uses the default protocol 295 authentication scope. This discovery method does not provide enough 296 information to locate other incompatible protocols. 298 For instance, an HTTPS server that is discovered using purely A or 299 AAAA records (and CNAME or DNAME records) might advertise support for 300 incompatible protocols, but as there is no way to determine where 301 those protocols are supported, a client cannot act on the 302 information. Note that Alternative Services do not change the 303 protocol authentication scope. 305 Deployments of discovery methods that define a protocol 306 authentication scope larger than the default need to ensure that 307 every server provides information that is consistent with every 308 protocol authentication scope that includes that server. A server 309 that fails to indicate support for a protocol that is within a 310 protocol authentication scope does not offer any protection against 311 attack; a server that advertises a protocol that the client cannot 312 discover risks this misconfiguration being identified as an attack by 313 clients. 315 6. Incompatible Protocol Selection 317 This represents a different model for protocol selection than the one 318 used by ALPN. In ALPN, the client presents a set of (compatible) 319 options and the server chooses its most preferred. 321 In comparison, as the client makes a selection between incompatible 322 protocols before making a connection attempt, this design only 323 provides the client with information about other incompatible 324 protocols that the server might support. Any choice to attempt a 325 connection using those protocols is left to the client. 327 In summary: 329 * For compatible protocols, the server chooses 331 * For incompatible protocols, the client chooses 333 Detecting a potential downgrade between incompatible protocols does 334 not automatically imply that a client abandon a connection attempt. 335 This is left to client policy. 337 For a protocol like HTTP/3, this might not result in the client 338 choosing to use HTTP/3, even if the server prefers that protocol. 339 Blocking of UDP or QUIC is known to be widespread. As a result, 340 clients might adopt a policy of tolerating a downgrade to a TCP-based 341 protocol, even if HTTP/3 were preferred. However, as blocking of UDP 342 is highly correlated by access network, clients that are able to 343 establish HTTP/3 connections to some servers might choose to apply a 344 stricter response when a server that indicates HTTP/3 support is 345 unreachable. 347 7. Security Considerations 349 This design depends on the integrity of the TLS handshake across all 350 forms, including TLS [RFC8446], DTLS [DTLS], and QUIC [QUIC-TLS]. An 351 attacker that can modify a TLS handshake in any one of these 352 protocols can cause a client to believe that other options do not 353 exist. 355 A server deployment that uses AliasForm SVCB records and does not 356 uniformly support a client-preferred protocol is vulnerable to 357 downgrade attacks that steer clients toward instances that lack 358 support for that protocol. This attack is ineffective for protocols 359 that are consistently supported by all server instances. 361 8. IANA Considerations 363 TODO: register the extension 365 9. References 367 9.1. Normative References 369 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 370 "Transport Layer Security (TLS) Application-Layer Protocol 371 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 372 July 2014, . 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 9.2. Informative References 385 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 386 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 387 April 2016, . 389 [DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 390 Datagram Transport Layer Security (DTLS) Protocol Version 391 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 392 dtls13-38, 29 May 2020, . 395 [HAPPY-EYEBALLS] 396 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 397 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 398 2012, . 400 [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1 401 Messaging", Work in Progress, Internet-Draft, draft-ietf- 402 httpbis-messaging-10, 12 July 2020, . 405 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 406 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 407 DOI 10.17487/RFC7540, May 2015, 408 . 410 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 411 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 412 quic-http-29, 9 June 2020, . 415 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 416 Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 417 9 June 2020, . 420 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 421 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 422 . 424 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 425 and parameter specification via the DNS (DNS SVCB and 426 HTTPSSVC)", Work in Progress, Internet-Draft, draft-ietf- 427 dnsop-svcb-httpssvc-03, 11 June 2020, 428 . 431 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 432 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 433 . 435 Appendix A. Acknowledgments 437 Author's Address 439 Martin Thomson 440 Mozilla 442 Email: mt@lowentropy.net