idnits 2.17.1 draft-ietf-httpbis-http2-encryption-05.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 (May 31, 2016) is 2888 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '443' on line 266 -- Looks like a reference, but probably isn't: '8000' on line 199 -- Looks like a reference, but probably isn't: '8080' on line 266 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Experimental M. Thomson 5 Expires: December 2, 2016 Mozilla 6 May 31, 2016 8 Opportunistic Security for HTTP 9 draft-ietf-httpbis-http2-encryption-05 11 Abstract 13 This document describes how "http" URIs can be accessed using 14 Transport Layer Security (TLS) to mitigate pervasive monitoring 15 attacks. 17 Note to Readers 19 Discussion of this draft takes place on the HTTP working group 20 mailing list (ietf-http-wg@w3.org), which is archived at 21 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 23 Working Group information can be found at http://httpwg.github.io/ ; 24 source code and issues list for this draft can be found at 25 https://github.com/httpwg/http-extensions/labels/opp-sec . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 2, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 3 63 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 64 2. Using HTTP URIs over TLS . . . . . . . . . . . . . . . . . . 3 65 3. Server Authentication . . . . . . . . . . . . . . . . . . . . 4 66 4. Interaction with "https" URIs . . . . . . . . . . . . . . . . 5 67 5. Requiring Use of TLS . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Opportunistic Commitment . . . . . . . . . . . . . . . . 6 69 5.2. Client Handling of A Commitment . . . . . . . . . . . . . 6 70 5.3. Operational Considerations . . . . . . . . . . . . . . . 7 71 6. The "http-opportunistic" well-known URI . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 8.1. Security Indicators . . . . . . . . . . . . . . . . . . . 8 75 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 8 76 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 9 77 8.4. Confusion Regarding Request Scheme . . . . . . . . . . . 9 78 8.5. Server Controls . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 This document describes a use of HTTP Alternative Services [RFC7838] 88 to decouple the URI scheme from the use and configuration of 89 underlying encryption, allowing a "http" URI [RFC7230] to be accessed 90 using Transport Layer Security (TLS) [RFC5246] opportunistically. 92 Serving "https" URIs require acquiring and configuring a valid 93 certificate, which means that some deployments find supporting TLS 94 difficult. This document describes a usage model whereby sites can 95 serve "http" URIs over TLS without being required to support strong 96 server authentication. 98 Opportunistic Security [RFC7435] does not provide the same guarantees 99 as using TLS with "https" URIs; it is vulnerable to active attacks, 100 and does not change the security context of the connection. 101 Normally, users will not be able to tell that it is in use (i.e., 102 there will be no "lock icon"). 104 A mechanism for partially mitigating active attacks is described in 105 Section 5. 107 1.1. Goals and Non-Goals 109 The immediate goal is to make the use of HTTP more robust in the face 110 of pervasive passive monitoring [RFC7258]. 112 A secondary goal is to limit the potential for active attacks. It is 113 not intended to offer the same level of protection as afforded to 114 "https" URIs, but instead to increase the likelihood that an active 115 attack can be detected. 117 A final (but significant) goal is to provide for ease of 118 implementation, deployment and operation. This mechanism is expected 119 to have a minimal impact upon performance, and require a trivial 120 administrative effort to configure. 122 1.2. Notational Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Using HTTP URIs over TLS 130 An origin server that supports the resolution of "http" URIs can 131 indicate support for this specification by providing an alternative 132 service advertisement [RFC7838] for a protocol identifier that uses 133 TLS, such as "h2" [RFC7540]. 135 A client that receives such an advertisement MAY make future requests 136 intended for the associated origin ([RFC6454]) to the identified 137 service (as specified by [RFC7838]). 139 A client that places the importance of protection against passive 140 attacks over performance might choose to withhold requests until an 141 encrypted connection is available. However, if such a connection 142 cannot be successfully established, the client can resume its use of 143 the cleartext connection. 145 A client can also explicitly probe for an alternative service 146 advertisement by sending a request that bears little or no sensitive 147 information, such as one with the OPTIONS method. Likewise, clients 148 with existing alternative services information could make such a 149 request before they expire, in order minimize the delays that might 150 be incurred. 152 3. Server Authentication 154 [RFC7838] requires that an alternative service only be used when 155 there are "reasonable assurances" that it is under control of and 156 valid for the whole origin. 158 As defined in that specification, a client can establish reasonable 159 assurances when using a TLS-based protocol with the certificate 160 checks defined in [RFC2818]. 162 For the purposes of this specification, an additional way of 163 establishing reasonable assurances is available when the alternative 164 is on the same host as the origin, using the "http-opportunistic" 165 well-known URI defined in Section 6. 167 This allows deployment without the use of valid certificates, to 168 encourage deployment of opportunistic security. When it is in use, 169 the alternative service can provide any certificate, or even select 170 TLS cipher suites that do not include authentication. 172 When a client has a valid http-opportunistic response for an origin 173 (as per Section 6), it MAY consider there to be reasonable assurances 174 as long as: 176 o The origin and alternative service's hostnames are the same when 177 compared in a case-insensitive fashion, and 179 o The origin object of the http-opportunistic response has a `tls- 180 ports' member, whose value is an array of numbers, one of which 181 matches the port of the alternative service in question, and 183 o The chosen alternative service returns the same representation as 184 the origin did for the http-opportunistic resource. 186 For example, this request/response pair would constitute reasonable 187 assurances for the origin "http://www.example.com" for an alternative 188 service on port 443 or 8000 of the host "www.example.com": 190 GET /.well-known/http-opportunistic HTTP/1.1 191 Host: www.example.com 193 HTTP/1.1 200 OK 194 Content-Type: application/json 195 Connection: close 197 { 198 "http://www.example.com": { 199 "tls-ports": [443, 8000] 200 } 201 } 203 Note that this mechanism is only defined to establish reasonable 204 assurances for the purposes of this specification; it does not apply 205 to other uses of alternative services unless they explicitly invoke 206 it. 208 4. Interaction with "https" URIs 210 When using alternative services, requests for resources identified by 211 both "http" and "https" URIs might use the same connection, because 212 HTTP/2 permits requests for multiple origins on the same connection. 214 Since "https" URIs rely on server authentication, a connection that 215 is initially created for "http" URIs without authenticating the 216 server cannot be used for "https" URIs until the server certificate 217 is successfully authenticated. Section 3.1 of [RFC2818] describes 218 the basic mechanism, though the authentication considerations in 219 Section 2.1 of [RFC7838] also apply. 221 Connections that are established without any means of server 222 authentication (for instance, the purely anonymous TLS cipher suites) 223 cannot be used for "https" URIs. 225 5. Requiring Use of TLS 227 Even when the alternative service is strongly authenticated, 228 opportunistically upgrading cleartext HTTP connections to use TLS is 229 subject to active attacks. In particular: 231 o Because the original HTTP connection is in cleartext, it is 232 vulnerable to man-in-the-middle attacks, and 234 o By default, if clients cannot reach the alternative service, they 235 will fall back to using the original cleartext origin. 237 Given that the primary goal of this specification is to prevent 238 passive attacks, these are not critical failings (especially 239 considering the alternative - HTTP over cleartext). However, a 240 modest form of protection against active attacks can be provided for 241 clients on subsequent connections. 243 When an origin is able to commit to providing service for a 244 particular origin over TLS for a bounded period of time, clients can 245 choose to rely upon its availability, failing when it cannot be 246 contacted. Effectively, this makes the choice to use a secured 247 protocol "sticky". 249 5.1. Opportunistic Commitment 251 An origin can reduce the risk of attacks on opportunistically secured 252 connections by committing to provide a secured, authenticated 253 alternative service. This is done by including the optional "tls- 254 commit" member in the origin object of the http-opportunistic well- 255 known response (see Section 6). 257 This feature is optional due to the requirement for server 258 authentication and the potential risk entailed (see Section 5.3). 260 The value of the "tls-commit" member is a number ([RFC7159], 261 Section 6) indicating the duration of the commitment interval in 262 seconds. 264 { 265 "http://www.example.com": { 266 "tls-ports": [443,8080], 267 "tls-commit": 3600 268 } 269 } 271 Including "tls-commit" creates a commitment to provide a secured 272 alternative service for the advertised period. Clients that receive 273 this commitment can assume that a secured alternative service will be 274 available for the indicated period. Clients might however choose to 275 limit this time (see Section 5.3). 277 5.2. Client Handling of A Commitment 279 The value of the "tls-commit" member MUST be ignored unless the 280 alternative service can be strongly authenticated. The same 281 authentication requirements that apply to "https://" resources SHOULD 282 be applied to authenticating the alternative. Minimum authentication 283 requirements for HTTP over TLS are described in Section 2.1 of 285 [RFC7838] and Section 3.1 of [RFC2818]. As noted in [RFC7838], 286 clients can impose other checks in addition to this minimum set. For 287 instance, a client might choose to apply key pinning [RFC7469]. 289 A client that receives a commitment and that successfully 290 authenticates the alternative service can assume that a secured 291 alternative will remain available for the commitment interval. The 292 commitment interval starts when the commitment is received and 293 authenticated and runs for a number of seconds equal to value of the 294 "tls-commit" member, less the current age of the http-opportunistic 295 response (as defined in Section 4.2.3 of [RFC7234]). Note that the 296 commitment interval MAY exceed the freshness lifetime of the "http- 297 opportunistic" resource. 299 A client SHOULD avoid sending requests via cleartext protocols or to 300 unauthenticated alternative services for the duration of the 301 commitment interval, except to discover new potential alternatives. 303 A commitment is not bound to a particular alternative service. 304 Clients are able to use alternative services that they become aware 305 of. However, once a valid and authenticated commitment has been 306 received, clients SHOULD NOT use an unauthenticated alternative 307 service. Where there is an active commitment, clients SHOULD ignore 308 advertisements for unsecured alternative services. A client MAY send 309 requests to an unauthenticated origin in an attempt to discover 310 potential alternative services, but these requests SHOULD be entirely 311 generic and avoid including credentials. 313 5.3. Operational Considerations 315 Errors in configuration of commitments has the potential to render 316 even the unsecured origin inaccessible for the duration of a 317 commitment. Initial deployments are encouraged to use short duration 318 commitments so that errors can be detected without causing the origin 319 to become inaccessible to clients for extended periods. 321 To avoid situations where a commitment causes errors, clients MAY 322 limit the time over which a commitment is respected for a given 323 origin. A lower limit might be appropriate for initial commitments; 324 the certainty that a site has set a correct value - and the 325 corresponding limit on persistence - might increase as a commitment 326 is renewed multiple times. 328 6. The "http-opportunistic" well-known URI 330 This specification defines the "http-opportunistic" well-known URI 331 [RFC5785]. A client is said to have a valid http-opportunistic 332 response for a given origin when: 334 o The client has obtained a 200 (OK) response for the well-known URI 335 from the origin, and it is fresh [RFC7234] (potentially through 336 revalidation [RFC7232]), and 338 o That response has the media type "application/json", and 340 o That response's payload, when parsed as JSON [RFC7159], contains 341 an object as the root. 343 o The root object contains a member whose name is a case-insensitive 344 character-for-character match for the origin in question, 345 serialised into Unicode as per Section 6.1 of [RFC6454], and whose 346 value is an object (hereafter, the "origin object"). 348 7. IANA Considerations 350 This specification registers a Well-Known URI [RFC5785]: 352 o URI Suffix: http-opportunistic 354 o Change Controller: IETF 356 o Specification Document(s): Section 6 of [this specification] 358 o Related Information: 360 8. Security Considerations 362 8.1. Security Indicators 364 User Agents MUST NOT provide any special security indicia when an 365 "http" resource is acquired using TLS. In particular, indicators 366 that might suggest the same level of security as "https" MUST NOT be 367 used (e.g., a "lock device"). 369 8.2. Downgrade Attacks 371 A downgrade attack against the negotiation for TLS is possible. With 372 commitment (see Section 5), this is limited to occasions where 373 clients have no prior information (see Section 8.3), or when 374 persisted commitments have expired. 376 For example, because the "Alt-Svc" header field [RFC7838] likely 377 appears in an unauthenticated and unencrypted channel, it is subject 378 to downgrade by network attackers. In its simplest form, an attacker 379 that wants the connection to remain in the clear need only strip the 380 "Alt-Svc" header field from responses. 382 Downgrade attacks can be partially mitigated using the "tls-commit" 383 member of the http-opportunistic well-known resource, because when it 384 is used, a client can avoid using cleartext to contact a supporting 385 server. However, this only works when a previous connection has been 386 established without an active attacker present; a continuously 387 present active attacker can either prevent the client from ever using 388 TLS, or offer its own certificate. 390 8.3. Privacy Considerations 392 Cached alternative services can be used to track clients over time; 393 e.g., using a user-specific hostname. Clearing the cache reduces the 394 ability of servers to track clients; therefore clients MUST clear 395 cached alternative service information when clearing other origin- 396 based state (i.e., cookies). 398 8.4. Confusion Regarding Request Scheme 400 HTTP implementations and applications sometimes use ambient signals 401 to determine if a request is for an "https" resource; for example, 402 they might look for TLS on the stack, or a server port number of 443. 404 This might be due to limitations in the protocol (the most common 405 HTTP/1.1 request form does not carry an explicit indication of the 406 URI scheme), or it may be because how the server and application are 407 implemented (often, they are two separate entities, with a variety of 408 possible interfaces between them). 410 Any security decisions based upon this information could be misled by 411 the deployment of this specification, because it violates the 412 assumption that the use of TLS (or port 443) means that the client is 413 accessing a HTTPS URI, and operating in the security context implied 414 by HTTPS. 416 Therefore, servers need to carefully examine the use of such signals 417 before deploying this specification. 419 8.5. Server Controls 421 Because this specification allows "reasonable assurances" to be 422 established by the content of a well-known URI, servers SHOULD take 423 suitable measures to assure that its content remains under their 424 control. Likewise, because the Alt-Svc header field is used to 425 describe policies across an entire origin, servers SHOULD NOT permit 426 user content to set or modify the value of this header. 428 9. References 430 9.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 438 DOI 10.17487/RFC2818, May 2000, 439 . 441 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 442 (TLS) Protocol Version 1.2", RFC 5246, 443 DOI 10.17487/RFC5246, August 2008, 444 . 446 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 447 Uniform Resource Identifiers (URIs)", RFC 5785, 448 DOI 10.17487/RFC5785, April 2010, 449 . 451 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 452 DOI 10.17487/RFC6454, December 2011, 453 . 455 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 456 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 457 2014, . 459 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 460 Protocol (HTTP/1.1): Message Syntax and Routing", 461 RFC 7230, DOI 10.17487/RFC7230, June 2014, 462 . 464 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 465 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 466 DOI 10.17487/RFC7232, June 2014, 467 . 469 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 470 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 471 RFC 7234, DOI 10.17487/RFC7234, June 2014, 472 . 474 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 475 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 476 DOI 10.17487/RFC7540, May 2015, 477 . 479 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 480 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 481 April 2016, . 483 9.2. Informative References 485 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 486 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 487 2014, . 489 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 490 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 491 December 2014, . 493 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 494 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 495 2015, . 497 Appendix A. Acknowledgements 499 Mike Bishop contributed significant text to this document. 501 Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen 502 Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam 503 Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard 504 Barnes for their feedback and suggestions. 506 Authors' Addresses 508 Mark Nottingham 510 Email: mnot@mnot.net 511 URI: http://www.mnot.net/ 513 Martin Thomson 514 Mozilla 516 Email: martin.thomson@gmail.com