idnits 2.17.1 draft-schinazi-masque-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 28, 2019) is 1885 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 370 -- Looks like a reference, but probably isn't: '2' on line 372 -- Looks like a reference, but probably isn't: '3' on line 374 -- Looks like a reference, but probably isn't: '4' on line 377 -- Looks like a reference, but probably isn't: '5' on line 380 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 == Outdated reference: A later version (-05) exists of draft-pauly-quic-datagram-02 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-http2-secondary-certs-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Experimental February 28, 2019 5 Expires: September 1, 2019 7 The MASQUE Protocol 8 draft-schinazi-masque-00 10 Abstract 12 This document describes MASQUE (Multiplexed Application Substrate 13 over QUIC Encryption). MASQUE is a mechanism that allows co-locating 14 and obfuscating networking applications behind an HTTPS web server. 15 The currently prevalent use-case is to allow running a VPN server 16 that is indistinguishable from an HTTPS server to any unauthenticated 17 observer. We do not expect major providers and CDNs to deploy this 18 behind their main TLS certificate, as they are not willing to take 19 the risk of getting blocked, as shown when domain fronting was 20 blocked. An expected use would be for individuals to enable this 21 behind their personal websites via easy to configure open-source 22 software. 24 This document is a straw-man proposal. It does not contain enough 25 details to implement the protocol, and is currently intended to spark 26 discussions on the approach it is taking. As we have not yet found a 27 home for this work, discussion is encouraged to happen on the GitHub 28 repository which contains the draft: 29 https://github.com/DavidSchinazi/masque-drafts [1]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 1, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 67 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Invisibility of VPN Usage . . . . . . . . . . . . . . . . 3 69 2.2. Invisibility of the Server . . . . . . . . . . . . . . . 3 70 2.3. Fallback to HTTP/2 over TLS over TCP . . . . . . . . . . 4 71 3. Overview of the Mechanism . . . . . . . . . . . . . . . . . . 4 72 4. Mechanisms the Server Can Advertise to Authenticated Clients 5 73 4.1. HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.2. DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . 5 75 4.3. UDP Proxying . . . . . . . . . . . . . . . . . . . . . . 5 76 4.4. IP Proxying . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 6 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 7.2. Informative References . . . . . . . . . . . . . . . . . 8 83 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 Design Justifications . . . . . . . . . . . . . . . . . . . . . . 9 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 This document describes MASQUE (Multiplexed Application Substrate 91 over QUIC Encryption). MASQUE is a mechanism that allows co-locating 92 and obfuscating networking applications behind an HTTPS web server. 93 The currently prevalent use-case is to allow running a VPN server 94 that is indistinguishable from an HTTPS server to any unauthenticated 95 observer. We do not expect major providers and CDNs to deploy this 96 behind their main TLS certificate, as they are not willing to take 97 the risk of getting blocked, as shown when domain fronting was 98 blocked. An expected use would be for individuals to enable this 99 behind their personal websites via easy to configure open-source 100 software. 102 This document is a straw-man proposal. It does not contain enough 103 details to implement the protocol, and is currently intended to spark 104 discussions on the approach it is taking. As we have not yet found a 105 home for this work, discussion is encouraged to happen on the GitHub 106 repository which contains the draft: 107 https://github.com/DavidSchinazi/masque-drafts [2]. 109 MASQUE leverages the efficient head-of-line blocking prevention 110 features of the QUIC transport protocol [I-D.ietf-quic-transport] 111 when MASQUE is used in an HTTP/3 [I-D.ietf-quic-http] server. MASQUE 112 can also run in an HTTP/2 server [RFC7540] but at a performance cost. 114 1.1. Conventions and Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Requirements 124 This section describes the goals and requirements chosen for the 125 MASQUE protocol. 127 2.1. Invisibility of VPN Usage 129 An authenticated client using the VPN appears to observers as a 130 regular HTTPS client. Observers only see that HTTP/3 or HTTP/2 is 131 being used over an encrypted channel. No part of the exchanges 132 between client and server may stick out. Note that traffic analysis 133 is currently considered out of scope. 135 2.2. Invisibility of the Server 137 To anyone without private keys, the server is indistinguishable from 138 a regular web server. It is impossible to send an unauthenticated 139 probe that the server would reply to differently than if it were a 140 normal web server. 142 2.3. Fallback to HTTP/2 over TLS over TCP 144 When QUIC is blocked, MASQUE can run over TCP and still satisfy 145 previous requirements. Note that in this scenario performance may be 146 negatively impacted. 148 3. Overview of the Mechanism 150 The server runs an HTTPS server on port 443, and has a valid TLS 151 certificate for its domain. The client has a public/private key 152 pair, and the server maintains a list of authorized MASQUE clients, 153 and their public key. (Alternatively, clients can also be 154 authenticated using a shared secret.) The client starts by 155 establishing a regular HTTPS connection to the server (HTTP/3 over 156 QUIC or HTTP/2 over TLS 1.3 [RFC8446] over TCP), and validates the 157 server's TLS certificate as it normally would for HTTPS. If 158 validation fails, the connection is aborted. The client then uses a 159 TLS keying material exporter [RFC5705] with label "EXPORTER-masque" 160 and no context to generate a 32-byte key. This key is then used as a 161 nonce to prevent replay attacks. The client then sends an HTTP 162 CONNECT request for "/.well-known/masque/initial" with the :protocol 163 pseudo-header field set to "masque", and a "Masque-Authentication:" 164 header. The MASQUE authentication header differs from the HTTP 165 "Authorization" header in that it applies to the underlying 166 connection instead of being per-request. It can use either a shared 167 secret or asymmetric authentication. The asymmetric variant uses 168 authentication method "PublicKey", and it transmits a signature of 169 the nonce with the client's public key encoded in base64 format, 170 followed by other information such as the client username and 171 signature algorithm OID. The symmetric variant uses authentication 172 method "HMAC" and transmits an HMAC of the nonce with the shared 173 secret instead of a signature. For example this header could look 174 like: 176 Masque-Authentication: PublicKey u="am9obi5kb2U=";a=1.3.101.112; 177 s="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo 178 aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==" 180 Masque-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3; 181 s="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo 182 aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==" 184 Figure 1: MASQUE Authentication Format Example 186 When the server receives this CONNECT request, it verifies the 187 signature and if that fails responds with code "405 Method Not 188 Allowed", making sure its response is the same as what it would 189 return for any unexpected CONNECT request. If the signature 190 verifies, the server responds with code "101 Switching Protocols", 191 and from then on this HTTP stream is now dedicated to the MASQUE 192 protocol. That protocol provides a reliable bidirectional message 193 exchange mechanism, which is used by the client and server to 194 negotiate what protocol options are supported and enabled by policy, 195 and client VPN configuration such as IP addresses. When using QUIC, 196 this protocol also allows endpoints to negotiate the use of QUIC 197 extensions, such as support for the DATAGRAM extension 198 [I-D.pauly-quic-datagram]. 200 4. Mechanisms the Server Can Advertise to Authenticated Clients 202 Once a server has authenticated the client's MASQUE CONNECT request, 203 it advertises services that the client may use. These services allow 204 for example varying degrees of proxying services to help a client 205 obfuscate the ultimate destination of their traffic. 207 4.1. HTTP Proxy 209 The client can make proxied HTTP requests through the server to other 210 servers. In practice this will mean using the CONNECT method to 211 establish a stream over which to run TLS to a different remote 212 destination. 214 4.2. DNS over HTTPS 216 The client can send DNS queries using DNS over HTTPS (DoH) [RFC8484] 217 to the MASQUE server. 219 4.3. UDP Proxying 221 In order to support WebRTC or QUIC to further servers, clients need a 222 way to relay UDP onwards to a remote server. In practice for most 223 widely deployed protocols other than DNS, this involves many 224 datagrams over the same ports. Therefore this mechanism implements 225 that efficiently: clients can use the MASQUE protocol stream to 226 request an UDP association to an IP address and UDP port pair. In 227 QUIC, the server would reply with a DATAGRAM_ID that the client can 228 then use to have UDP datagrams sent to this remote server. Datagrams 229 are then simply transferred between the DATAGRAMs with this ID and 230 the outer server. There will also be a message on the MASQUE 231 protocol stream to request shutdown of a UDP association to save 232 resources when it is no longer needed. When running over TCP, the 233 client opens a new stream with a CONNECT request to the "masque-udp- 234 proxy" protocol and then sends datagrams encapsulated inside the 235 stream with a two-byte length prefix in network byte order. The 236 target IP and port are sent as part of the URL query. Resetting that 237 stream instructs the server to release any associates resources. 239 4.4. IP Proxying 241 For the rare cases where the previous mechanisms are not sufficient, 242 proxying can be performed at the IP layer. This would use a 243 different DATAGRAM_ID and IP datagrams would be encoded inside it 244 without framing. Over TCP, a dedicated stream with two byte length 245 prefix would be used. The server can inspect the IP datagram to look 246 for the destination address in the IP header. 248 4.5. Path MTU Discovery 250 In the main deployment of this mechanism, QUIC will be used between 251 client and server, and that will most likely be the smallest MTU link 252 in the path due to QUIC header and authentication tag overhead. The 253 client is responsible for not sending overly large UDP packets and 254 notifying the server of the low MTU. Therefore PMTUD is currently 255 seen as out of scope of this document. 257 5. Security Considerations 259 Here be dragons. TODO: slay the dragons. 261 6. IANA Considerations 263 We will need to register: 265 o the TLS keying material exporter label "EXPORTER-masque" (spec 266 required) 268 https://www.iana.org/assignments/tls-parameters/tls- 269 parameters.xhtml#exporter-labels [3] 271 o the new HTTP header "Masque-Authentication" 273 https://www.iana.org/assignments/message-headers/message- 274 headers.xhtml [4] 276 o the "/.well-known/masque/" URI (expert review) 278 https://www.iana.org/assignments/well-known-uris/well-known- 279 uris.xhtml [5] 281 o The "masque" and "masque-udp-proxy" extended HTTP CONNECT 282 protocols 284 We will also need to define the MASQUE control protocol and that will 285 be likely to define new registries of its own. 287 7. References 289 7.1. Normative References 291 [I-D.ietf-quic-http] 292 Bishop, M., "Hypertext Transfer Protocol Version 3 293 (HTTP/3)", draft-ietf-quic-http-18 (work in progress), 294 January 2019. 296 [I-D.ietf-quic-transport] 297 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 298 and Secure Transport", draft-ietf-quic-transport-18 (work 299 in progress), January 2019. 301 [I-D.pauly-quic-datagram] 302 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 303 Datagram Extension to QUIC", draft-pauly-quic-datagram-02 304 (work in progress), February 2019. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 312 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 313 March 2010, . 315 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 316 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 317 DOI 10.17487/RFC7540, May 2015, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 325 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 326 . 328 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 329 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 330 . 332 7.2. Informative References 334 [I-D.ietf-httpbis-http2-secondary-certs] 335 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 336 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 337 http2-secondary-certs-03 (work in progress), October 2018. 339 [I-D.pardue-httpbis-http-network-tunnelling] 340 Pardue, L., "HTTP-initiated Network Tunnelling (HiNT)", 341 draft-pardue-httpbis-http-network-tunnelling-01 (work in 342 progress), October 2018. 344 [I-D.schwartz-httpbis-helium] 345 Schwartz, B., "Hybrid Encapsulation Layer for IP and UDP 346 Messages (HELIUM)", draft-schwartz-httpbis-helium-00 (work 347 in progress), June 2018. 349 [I-D.sullivan-tls-post-handshake-auth] 350 Sullivan, N., Thomson, M., and M. Bishop, "Post-Handshake 351 Authentication in TLS", draft-sullivan-tls-post-handshake- 352 auth-00 (work in progress), August 2016. 354 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 355 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 356 DOI 10.17487/RFC7427, January 2015, 357 . 359 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 360 RFC 8441, DOI 10.17487/RFC8441, September 2018, 361 . 363 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 364 "The Token Binding Protocol Version 1.0", RFC 8471, 365 DOI 10.17487/RFC8471, October 2018, 366 . 368 7.3. URIs 370 [1] https://github.com/DavidSchinazi/masque-drafts 372 [2] https://github.com/DavidSchinazi/masque-drafts 374 [3] https://www.iana.org/assignments/tls-parameters/tls- 375 parameters.xhtml#exporter-labels 377 [4] https://www.iana.org/assignments/message-headers/message- 378 headers.xhtml 380 [5] https://www.iana.org/assignments/well-known-uris/well-known- 381 uris.xhtml 383 Acknowledgments 385 This proposal was inspired directly or indirectly by prior work from 386 many people. In particular, this work is related to 387 [I-D.schwartz-httpbis-helium] and 388 [I-D.pardue-httpbis-http-network-tunnelling]. The mechanism used to 389 run the MASQUE protocol over HTTP/2 streams was inspired by 390 [RFC8441]. Using the OID for the signature algorithm was inspired by 391 Signature Authentication in IKEv2 [RFC7427]. 393 The author would like to thank Christophe A., an inspiration and true 394 leader of VPNs. 396 Design Justifications 398 Using an exported key as a nonce allows us to prevent replay attacks 399 (since it depends on randomness from both endpoints of the TLS 400 connection) without requiring the server to send an explicit nonce 401 before it has authenticated the client. Adding an explicit nonce 402 mechanism would expose the server as it would need to send these 403 nonces to clients that have not been authenticated yet. 405 The rationale for a separate MASQUE protocol stream is to allow 406 server-initiated messages. If we were to use HTTP semantics, we 407 would only be able to support the client-initiated request-response 408 model. We could have used WebSocket for this purpose but that would 409 have added wire overhead and dependencies without providing useful 410 features. 412 There are many other ways to authenticate HTTP, however the 413 authentication used here needs to work in a single client-initiated 414 message to meet the requirement of not exposing the server. 416 The current proposal would also work with TLS 1.2, but in that case 417 TLS false start and renegotiation must be disabled, and the extended 418 master secret and renegotiation indication TLS extensions must be 419 enabled. 421 If the server or client want to hide that HTTP/2 is used, the client 422 can set its ALPN to an older version of HTTP and then use the Upgrade 423 header to upgrade to HTTP/2 inside the TLS encryption. 425 The client authentication used here is similar to how Token Binding 426 [RFC8471] operates, but it has very different goals. MASQUE does not 427 use token binding directly because using token binding requires 428 sending the token_binding TLS extension in the TLS ClientHello, and 429 that would stick out compared to a regular TLS connection. 431 TLS post-handshake authentication 432 [I-D.sullivan-tls-post-handshake-auth] is not used by this proposal 433 because that requires sending the "post_handshake_auth" extension in 434 the TLS ClientHello, and that would stick out from a regular HTTPS 435 connection. 437 Client authentication could have benefited from Secondary Certificate 438 Authentication in HTTP/2 [I-D.ietf-httpbis-http2-secondary-certs], 439 however that has two downsides: it requires the server advertising 440 that it supports it in its SETTINGS, and it cannot be sent unprompted 441 by the client, so the server would have to request authentication. 442 Both of these would make the server stick out from regular HTTP/2 443 servers. 445 MASQUE proposes a new client authentication method (as opposed to 446 reusing something like HTTP basic authentication) because HTTP 447 authentication methods are conceptually per-request (they need to be 448 repeated on each request) whereas the new method is bound to the 449 underlying connection (be it QUIC or TLS). In particular, this 450 allows sending QUIC DATAGRAM frames without authenticating every 451 frame individually. Additionally, HMAC and asymmetric keying are 452 preferred to sending a password for client authentication since they 453 have a tighter security bound. Going into the design rationale, 454 HMACs (and signatures) need some data to sign, and to avoid replay 455 attacks that should be a fresh nonce provided by the remote peer. 456 Having the server provide an explicit nonce would leak the existence 457 of the server so we use TLS keying material exporters as they provide 458 us with a nonce that contains entropy from the server without 459 requiring explicit communication. 461 Author's Address 463 David Schinazi 464 Google LLC 465 1600 Amphitheatre Parkway 466 Mountain View, California 94043 467 United States of America 469 Email: dschinazi.ietf@gmail.com