idnits 2.17.1 draft-iesg-using-http-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 185 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '... This docum...' == Line 12 has weird spacing: '...its working g...' == Line 16 has weird spacing: '...months and ma...' == Line 17 has weird spacing: '... It is inapp...' == Line 20 has weird spacing: '... To view ...' == (180 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2068 (ref. '1') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2069 (ref. '2') (Obsoleted by RFC 2617) == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. '3') ** Obsolete normative reference: RFC 821 (ref. '6') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2222 (ref. '7') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2376 (ref. '11') (Obsoleted by RFC 3023) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet-Draft University of Tennessee 3 5 August 1998 Patrik Faltstrom 4 Expires: 5 February 1999 Tele2 6 On the use of HTTP as a Substrate for Other Protocols 8 draft-iesg-using-http-00.txt 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents at 17 any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 23 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 24 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 Recently there has been widespread interest in using Hypertext 29 Transport Protocol (HTTP) as a substrate for other applications-level 30 protocols. This document relates current IESG and IAB thinking on 31 technical particulars of such use, including use of default ports, URL 32 schemes, and HTTP security mechanisms. This thinking is subject to 33 change as discussion continues and more experience is gained with such 34 use. 36 1. Introduction 38 Recently there has been widespread interest in using Hypertext 39 Transport Protocol (HTTP) [1] as a substrate for other applications- 40 level protocols. Various reasons cited for this interest have included: 42 o familiarity and mindshare, 44 o compatibility with widely deployed browsers, 46 o ability to reuse existing servers and client libraries, 47 o ease of prototyping servers using CGI scripts and similar extension 48 mechanisms, 50 o ability to use existing security mechanisms such as HTTP digest 51 authentication [2] and SSL or TLS [3], 53 o the ability of HTTP to traverse firewalls, and 55 o cases where a server often needs to support HTTP anyway. 57 The Internet community has a long tradition of protocol reuse, 58 dating back to the use of Telnet [4] as a substrate for FTP [5] and SMTP 59 [6]. However, the recent interest in layering new protocols over HTTP 60 has raised a number of questions when such use is appropriate, and the 61 proper way to use HTTP in contexts where it is appropriate. 62 Specifically, for a given application that is layered on top of HTTP: 64 o Should the application use a different port than the HTTP default 65 of 80? 67 o Should the application use traditional HTTP methods (GET, POST, 68 etc.) or should it define new methods? 70 o Should the application use http: URLs or define its own prefix? 72 o Should the application define its own MIME-types, or use something 73 that already exists (like registering a new type of MIME-directory 74 structure)? 76 This memo attempts to illustrate the current thinking of the 77 Applications Area Directors and other members of IESG and IAB, on these 78 questions. The answers to some of these questions may change over time 79 as discussions on these issues continue, or as the community acquires 80 additional experience. 82 We also expect that these recommendations may eventually be 83 superseded by a working group chartered to establish mechanisms for 84 layering new protocols over a subset of HTTP. 86 2. Issues Regarding the Design Choice to use HTTP 88 Despite the advantages listed above, it's worth asking the question 89 as to whether HTTP should be used at all, or whether the entire HTTP 90 protocol should be used. 92 2.1 Complexity 94 HTTP started out as a simple protocol, but quickly became much more 95 complex due to the addition of several features unanticipated by its 96 original design. These features include persistent connections, byte 97 ranges, content negotiation, and cache support. All of these are useful 98 for traditional web applications but may not be useful for the layered 99 application. The need to support (or circumvent) these features can add 100 additional complexity to the design and implementation of a protocol 101 layered on top of HTTP. Even when HTTP can be "profiled" to minimize 102 implementation overhead, the effort of specifying such a profile might 103 be more than the effort of specifying a purpose-built protocol which is 104 better suited to the task at hand. Even if existing HTTP client and 105 server code can often be re-used, the additional complexity of HTTP over 106 a purpose-built protocol can increase the number of interoperability 107 problems. 109 2.2 Overhead 111 Further, although HTTP can be used as the transport for a "remote 112 procedure call" paradigm, HTTP's protocol overhead, along with the 113 connection setup overhead of TCP, can make HTTP a poor choice. A 114 protocol based on UDP, or with both UDP and TCP variants, should be 115 considered if the payloads are very likely to be small (less than a few 116 hundred bytes) for the foreseeable future. This is especially true if 117 the protocol might be heavily used. 119 On the other hand, the connection setup overhead can become 120 negligible if the layered protocol can utilize HTTP/1.1's persistent 121 connections, and if the same client and server are likely to perform 122 several transactions during the time the HTTP connection is open. 124 2.3 Security 126 Although HTTP appears at first glance to be one of the few "mature" 127 Internet protocols that can provide good security, there are many 128 applications for which neither HTTP's digest authentication nor TLS are 129 sufficient by themselves. 131 Digest authentication requires a secret (e.g. a password) to be 132 shared between client and server. This further requires that each 133 client know the secret to be used with each server, but it does not 134 provide any means of securely transmitting such secrets between the 135 parties. Shared secrets can work fine for small groups where everyone 136 is physically co-located; they don't work as well for large or dispersed 137 communities of users. Further, if the server is compromised a large 138 number of secrets may be exposed, which is especially dangerous if the 139 same secret (or password) is used for several applications. 141 TLS is descended from SSL, which was originally designed to 142 authenticate servers to clients - not the other way around. Even though 143 TLS now provides mutual authentication, a client that needs to talk to 144 multiple servers must still know which credentials to present to each 145 server before establishing a secure connection to the server. Client 146 and server must each use private keys that are trusted by the other 147 party - typically because they are signed by a certificate authority 148 (CA) known to the other. As in the digest authentication case, both 149 client and server need ways to protect their private keys against 150 exposure. 152 Web browsers typically are shipped with the public keys of several 153 CAs "wired in" so that they can verify the identity of any server whose 154 public key was signed by one of those CAs. This deployment model does 155 not necessarily work well for other applications, and it doesn't provide 156 any way for a server to verify a client's identity. Even if the 157 client's CA is recognized by the server, this doesn't necessarily convey 158 authorization to use the service. Existing clients and servers may 159 therefore lack the mechanisms needed for robust authentication using TLS 160 or SSL and HTTP. 162 For any application that requires privacy, the 40-bit encryption 163 provided by "US exportable" SSL implementations is unsuitable. Even 164 56-bit DES encryption, which is required by TLS, has been broken in a 165 matter of days with a modest investment. 167 None of the above should be taken to mean that digest 168 authentication or TLS are generally unsuitable for use in other 169 applications - only that they are not a "magic pixie dust" solution to 170 either authentication or privacy. An application's designers should 171 carefully determine the application's users' requirements for 172 authentication and privacy before automatically choosing TLS or digest 173 authentication. 175 Note also that TLS can be used with other TCP-based protocols, and 176 there are SASL [7] mechanisms similar to HTTP's digest authentication. 177 So even if TLS and/or digest are suitable for an application, this does 178 not imply that HTTP should be used. 180 2.4 Compatibility with Proxies and Firewalls 182 One oft-cited reason for the use of HTTP is its ability to pass 183 through proxies or firewalls. Firewalls are an unfortunate consequence 184 of the Internet's explosive growth, in that they decrease the 185 deployability of new Internet applications, by requiring explicit 186 permission (or even a software upgrade) to accommodate each new 187 protocol. 189 However, the IESG takes the view that if a site's firewall prevents 190 the use of unknown protocols, this is a conscious policy decision on the 191 part of the firewall administrator. While it is arguable whether or not 192 new protocols should be "firewall-friendly", they should definitely not 193 be "firewall-hostile". In particular, new protocols should not attempt 194 to circumvent a site's security policy. 196 We hope to eventually establish guidelines for "firewall-friendly" 197 protocols, to make it easier for existing firewalls to be compatible 198 with new protocols. 200 2.5 Questions to be asked when considering use of HTTP 202 o When considering payload size and traffic patterns, is HTTP an 203 appropriate transport for the anticipated use of this protocol? 205 o Is this new protocol usable by existing web browsers without 206 modification? 208 o Are the existing HTTP security mechanisms appropriate for the new 209 application? 211 o Does the server for this application need to support HTTP anyway? 213 3. Issues Regarding Reuse of Port 80 215 IANA has reserved TCP port number 80 for use by HTTP. IESG will 216 not allow a substantially new service, even one which uses HTTP as a 217 substrate, to usurp port 80 from its traditional use. IESG is likely to 218 consider a new use of HTTP a "substantially new service", and thus 219 requiring a new port, if any of the following are true: 221 o The "new service" and traditional HTTP service are likely to 222 reference different sets of data, even when they both operate on 223 the same host. 225 o There is a good reason for the "new service" to be implemented by a 226 separate server process, or separate code, than traditional HTTP 227 service on the same host, at least on some platforms. 229 o There is a good reason to want to easily distinguish the traffic of 230 the "new service" from traditional HTTP, e.g. for the purposes of 231 firewall access control or traffic analysis. 233 o If none of the above are true, IESG is likely to consider the new 234 use of HTTP an "extension" to traditional HTTP, rather than a "new 235 service". Extensions to HTTP which share data with traditional 236 HTTP services should probably define new HTTP methods to describe 237 those extensions, rather than using separate ports. If separate 238 ports are used, there is no way for a client to know whether they 239 are separate services or different ways of accessing the same 240 underlying service. 242 4. Issues Regarding Reuse of the http: Scheme in URLs 244 A number of different URL schemes are in widespread use and many 245 more are in the process of being standardized. In practice, the URL 246 scheme not only serves as a "tag" to govern the interpretation of the 247 remaining portion of the URL, it also provides coarse identification of 248 the "type" of resource or service. This is used, for instance, by web 249 browsers that provide a different response when a user mouse-clicks on 250 an "http" URL, than when the user clicks on a "mailto" URL. 252 It is ultimately IESG's responsibility to determine whether a 253 resource accessed by a protocol that is layered on top of HTTP, should 254 use http: or some other URL prefix. Among the criteria that IESG is 255 likely to consider in making this determination, are: 257 o Whether this URL is likely to become widely used, versus used only 258 in limited communities or by private agreement. 260 o Whether a new "default port" is needed. A new "default port" 261 requires a new URL type. Explicit port numbers in URLs are 262 regarded as an "escape hatch", not something for use in ordinary 263 circumstances. 265 o Whether use of the new service is likely to require a substantially 266 different setup or protocol interaction with the server, than 267 ordinary HTTP service. This could include the need to request a 268 different type of service, or to reserve bandwidth, or to present 269 different TLS authentication credentials to the server, or any 270 number of other needs. 272 o Whether user interfaces (such as web browsers) are likely to be 273 able to exploit the difference in the URL prefix to produce a 274 significant improvement in usability. 276 Note that the convention of appending an "s" to the URL scheme to 277 mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and 278 should not be propagated. For most applications, a single "use TLS or 279 SSL" bit is not sufficient to adequately convey the information that a 280 client needs to authenticate itself to a server, even if it has the 281 proper credentials. Authentication or other connection setup 282 information should be communicated in URL parameters, rather than in the 283 URL prefix. 285 5. Issues regarding use of MIME media types 287 Since HTTP uses the MIME media type system [8] to label its 288 payload, many applications which layer on HTTP will need to define, or 289 select, MIME media types for use by that application. Especially when 290 using a multipart structure, the choice of media types requires careful 291 consideration. In particular: 293 o Should some existing framework be used, such as text/directory [9], 294 or XML [10,11], or should the new content-types be built from 295 scratch? Just as with HTTP, it's useful if code can be reused, but 296 protocol designers should not be over-eager to incorporate a gen- 297 eral but complex framework into a new protocol. Experience with 298 ASN.1, for example, suggests that the advantage of using a general 299 framework may not be worth the cost. 301 o If it is at all useful to be able to use the same payload over 302 email, the differences between HTTP encoding of the payload and 303 email encoding of the payload should be minimized. Ideally, there 304 should be no differences in the "canonical form" used in the two 305 environments. Text/* media types can be problematic in this regard 306 because MIME email requires CRLF for line endings of text/* body 307 parts, where HTTP traditionally uses LF only. 309 o Different "commands" or "operations" on the same kind of object can 310 be communicated in a number of different ways, including different 311 HTTP methods, different Content-Types, different Content-Type 312 parameters, the Content-Disposition field, or inside the payload. 313 Different protocols have solved this problem in different ways. 314 Again, if it's desirable to provide the same services over elec- 315 tronic mail, the means of communicating the operation should ide- 316 ally be the same in both environments. 318 6. Issues Regarding Existing vs. New HTTP Methods 320 It has been suggested that a new service layered on top of HTTP 321 should define one or more new HTTP methods, rather than allocating a new 322 port. This may be useful, but is not sufficient in all cases. The 323 definition of one or more new methods for use in a new protocol, does 324 not by itself alleviate the need for use of a new port, or a new URL 325 type. 327 7. Issues regarding reuse of HTTP client, server, and proxy code 329 As mentioned earlier, one of the prime reasons for the use of HTTP 330 as a substrate for new protocols, is to allow reuse of existing HTTP 331 client, server, or proxy code. However, HTTP was not designed for such 332 layering. Existing HTTP client and code may have "http" assumptions 333 wired into them. For instance, client libraries and proxies may expect 334 "http:" URLs, and clients and servers may send (and expect) "HTTP/1.1", 335 in requests and responses, as opposed to the name of the layered 336 protocol and its version number. 338 Existing client libraries may not understand new URL types. In 339 order to get a new HTTP-layered application client to work with an 340 existing client library, the application may need to convert its URLs to 341 an "http equivalent" form. For instance, if service "xyz" is layered on 342 top of HTTP using port ###, the xyz client may need to translate URLs of 343 the form "xyz://host/something" to "http://host:###/something" for the 344 purpose of calling the existing HTTP client library. This should be 345 done ONLY when calling the HTTP client library - such URLs should not be 346 used in other parts of the protocol, nor should they be exposed to 347 users. 349 Note that when a client is sending requests directly to an origin 350 server, the URL prefix ("http:") is not normally sent. So translating 351 xyz: URLs to http: URLs when calling the client library should not 352 actually cause http: URLs to be sent over the wire. But when the same 353 client is sending requests to a proxy server, the client will normally 354 send the entire URL (including the http: prefix) in those requests. The 355 proxy will remove the URL prefix when the request is communicated to the 356 origin server. 358 Existing clients and servers will transmit "HTTP/1.1" (or a 359 different version) in requests and responses. To facilitate reuse of 360 existing code, protocols layered on top of HTTP must therefore transmit 361 and accept "HTTP/1.1" rather than their own protocol name and version 362 number. This may change in the future if client libraries and servers 363 gain more flexibility. 365 For certain applications it may be necessary to require or limit 366 use of certain HTTP features, for example, to defeat caching of 367 responses by proxies. Each protocol layered on HTTP must therefore 368 specify the specific way that HTTP will be used, and in particular, how 369 the client and server should interact with HTTP proxies. 371 HTTP's three-digit status codes were designed for use with 372 traditional HTTP applications, and may not be suitable to communicate 373 the specifics of errors encountered in other applications. HTTP status 374 codes should therefore not be used to indicate subtle errors of layered 375 applications. They should be re-used only to indicate errors with, or 376 the status of, the HTTP protocol layer; or to indicate the inability of 377 the HTTP server to communicate with the application server. 379 8. Summary of IESG Policy regarding reuse of HTTP 381 1. All standards-track protocols must provide adequate security. The 382 security needs of a particular application will vary widely 383 depending on the application and its anticipated use environment. 384 Merely using HTTP and/or TLS as a substrate for a protocol does not 385 automatically provide adequate security for all environments, nor 386 does it relieve the protocol developers of the need to analyze 387 security considerations. 389 2. New standards-track protocols - including those using HTTP - must 390 not attempt to circumvent users' firewall policies, particularly by 391 masquerading as existing protocols. "Substantially new services" 392 will not be allowed to re-use existing ports. 394 3. New services should use new URL types. 396 4. Each new protocol specification that uses HTTP as a substrate must 397 describe the specific way that HTTP is to be used by that protocol, 398 including how the client and server interact with proxies. 400 5. New services should define their own error reporting mechanisms, 401 and use HTTP status codes only for communicating the state of the 402 HTTP protocol. 404 9. Security Considerations 406 Much of this document is about security. Section 2.3 discusses 407 whether HTTP security is adequate for the needs of a particular 408 application, section 2.4 discusses interactions between new HTTP-based 409 protocols and firewalls, section 3 discusses use of separate ports so 410 that firewalls are not circumvented, and section 4 discusses the 411 inadequacy of the "s" suffix of a URL prefix for specifying security 412 levels. 414 10. Authors' addresses 415 Keith Moore 416 University of Tennessee, Knoxville 417 104 Ayres Hall 418 Knoxville TN, 37996-1301 419 USA 420 email: moore@cs.utk.edu 422 Patrik Faltstrom 423 Borgarfjordsgatan 16 424 BOX 64 425 162 92 Kista 426 Sweden 427 email: paf@swip.net 429 11. References 431 [1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. 432 Hypertext Transfer Protocol -- HTTP/1.1. RFC 2068, January 1997. 434 [2] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. 435 Sink, L. Stewart. An Extension to HTTP: Digest Access 436 Authentication. RFC 2069, January 1997. 438 [3] C. Allen, T. Dierks. The TLS Protocol Version 1.0. Internet-Draft 439 draft-ietf-tls-protocol-05.txt (work in progress). November 1997. 441 [4] J. Postel, J.K. Reynolds. Telnet Protocol Specification. RFC 854, 442 May 1983. 444 [5] J. Postel, J.K. Reynolds. File Transfer Protocol. RFC 959, October 445 1985. 447 [6] J. Postel. Simple Mail Transfer Protocol. RFC 821, August 1982. 449 [7] J. Myers. Simple Authentication and Security Layer (SASL). RFC 450 2222, October 1997. 452 [8] N. Freed, N. Borenstein. Multipurpose Internet Mail Extensions 453 (MIME) Part Two: Media Types. RFC 2046, November 1996. 455 [9] T. Howes, M. Smith, F. Dawson Jr. A MIME Content-Type for 456 Directory Information. Internet-Draft , July 1998. (work in progress) 459 [10] T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup 460 Language (XML)". World Wide Web Consortium Recommendation REC- 461 xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 463 [11] E. Whitehead, M. Murata. XML Media Types. RFC 2376, July 1998.