idnits 2.17.1 draft-debry-http-usepost-00.txt: -(43): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 6 months document validity. ** 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. == There is 1 instance of lines with non-ascii characters in the document. == 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 Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 27 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 134 has weird spacing: '...ders is that ...' == Line 167 has weird spacing: '...Perhaps this ...' == Line 201 has weird spacing: '..., in of itsel...' -- 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.) -- The document date (February 19, 1998) is 9562 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 130, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Roger deBry, IBM 3 Carl Kugler, IBM 4 Stee Gebert, IBM 5 Harry Lewis, IBM 6 Don Wright, Lexmark 7 Scott Isaacson, Noell 8 Tom Hasting, Xerox 10 Expires: July 1998 February 19, 1998 11 The Use of Post: 12 A Response to 14 Status of this Document 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. Internet-Drafts are draft 20 documents alid for a maximum of six months and may be updated, 21 replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet-Drafts as reference material or to cite 23 them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). Distribution of this document is 30 unlimited. Please send comments to the IPP working group at 31 ipp@pwg.org. 33 Abstract 35 A recent Internet Draft [1] argues that the common use of POST to 36 proide a uniform method of passing blocks of data to an application, 37 is being misused in the definition of new application protocols, such 38 as the Internet Printing Protocol. Cohen et. al. argue that a new 39 PUSH method be defined for this purpose. This Internet Draft argues 40 that the existing POST method proides all of the required 41 functionality for back end applications, such as Print, without 42 sacrificing the leels of security that customers expect. More 43 importantly, from the customer�s point of iew, it does this without 44 any impact to existing, installed network components. 46 Josh Cohen et. al., hae published an Internet Draft which provides a 47 set of arguments for not oerloading the POST method in HTTP. They 48 admit that in part their argument is a philosophical one. In 49 responding to the philosophical issues, let us first look carefully 50 at the definition of POST in the HTTP/1.1 Specification. In part, it 51 says: 53 "POST is designed to allow a uniform method to coer the following 54 functions: 56 - Annotations of existing resources 57 - Posting a message to a bulletin board, newsgroup, mailing list, or 58 similar group of articles 59 - Proiding a block of data, such as the result of submitting a 60 form, to a data handling process 61 - Extending a database through an append operation" 63 Let's focus on the third bullet, that is, proiding a block of data 64 to a data handling process. It is this use of POST which forms the 65 cornerstone of many modern Web Applications. Visit Microsoft's own 66 web site to see numerous examples of data drien applications and e- 67 commerce applications which depend upon HTTP to pass data through the 68 web serer to some back end application. These are not simple forms 69 drien applications, but use highly developed tools and technologies, 70 such as serlets, server side scripts, and ActiveX components, to 71 drie complex mission-critical applications. Indeed, the CGI 72 interface and arious Web server APIs were built specifically to 73 exploit this ability of the POST method to uniformly ship data to an 74 application on the other side of the Web serer. Aviel Rubin [2], et 75 al. in discussing the alue of this interface in their book on Web 76 Security say that: 78 "If you are building a complex Web serer site and are taking 79 adantage of new application protocols, you may run into cases 80 where firewalls interfere with your application's traffic. For 81 this reason, it is best, whereer possible, to use applications 82 that run on top of HTTP." 84 From a philosophical point of iew Cohen et. al. would have us 85 beliee that, in the case of IPP [3], we should not use POST to 86 transport a Print request to a back end print application. Instead, 87 he suggests a new method should be defined. It is interesting to note 88 that he stops short of suggesting that a Data Base QUERY method be 89 defined when using HTTP to direct a query to a back end data base 90 application, or a BUY method be defined when using HTTP to buy 91 something oer the Web, or a TRANSACT method be defined when using 92 HTTP to initiate a transaction to make an airline reseration. Are 93 these applications less sensitie to security intrusions than Print? 94 It is obious that using POST to provide a block of data to a data 95 handling process is common practice. Should printing really be 96 treated differently?" 98 From a philosophical point of iew, one is also led to ask, Does 99 defining a new method (or methods) in HTTP make the object of those 100 new methods part of HTTP? I would guess that if I were on the HTTP 101 working group, I'd hae something to say about someone else creating 102 a new HTTP method. It is perhaps for this reason that Cohen et. al. 103 appear to back away from their original thesis that "the default 104 requirement for (any) new HTTP functionality must be to create a new 105 method name", and propose a single new method called PUSH. 106 According to Cohen et. al., PUSH "would be a generic POST ... which 107 would require a secondary expression of specific operational 108 semantics along with the request message". 110 We claim that this capability already exists today in the content- 111 type header which is part of an existing HTTP message. In fact, the 112 IPP protocol makes use of a new content-type, Application/IPP, to 113 proide this "secondary expression of specific operational 114 semantics". Cohen et. al. claim that content-type should not imply 115 any semantics, but note this paragraph from the MIME specification 116 [4] which describes the application media type: "The application 117 media type is to be used for discrete data which do not fit in any of 118 the other categories, and particularly for data to be processed by 119 some type of application program." It seems therefore that a 120 content type of application/xxx is perfectly suited to proide Cohen 121 et. al.'s additional expression of operational semantics, and 122 requires no change to the existing HTTP definition or to existing Web 123 software. Cohen et. al. say that using content-type is also an 124 exposure, because I can lie about the content-type. Isn't it just as 125 easy to lie about a new method, or the suggested secondary 126 expression? Een if we were to accept Cohen et. al.'s assertion that 127 a new method is required, we would find it difficult to use anything 128 other than the existing header structure of HTTP to carry the 129 additional expression that Cohen et. al. suggests is required. An 130 Internet Draft on HTTP extensions [5] supports this notion when it 131 says that "Header fields can be used to pass information about any 132 of the parties inolved in the transaction, the transaction itself, 133 or the resource identified by the Request-URI. The adantage of 134 headers is that the header space is relatiely open compared to that 135 of methods and status codes. New headers can be introduced and must 136 be ignored if the recipient does not recognize the header without 137 affecting the outcome of the transaction ." 139 The technical basis of Cohen et. al.'s dissertation is that 140 oerloading the POST method subverts existing security policies 141 within organizations which may implement a protocol, such as IPP, 142 which uses POST. Cohen et. al. point out that PFB administrators 143 (PFB is a term coined by Cohen et al., and stands for Proxy/Firewall 144 Boundary) today can choose among characteristics like source port, 145 destination port, header prologue, HTTP method, mime-type, 146 as well as others. Why isn't this sufficient? Today I can clearly 147 define which resources (in the case of IPP, which printers), if 148 any, are accessible from outside of my PFB. I can restrict access 149 to resources to be from specific domains or IP addresses. I can 150 further proide TLS authentication on top of PFB access to protect 151 myself from unauthorized use of my resources. In this sense, why 152 is access to some new function, such as print, any different from 153 access to a database, a transaction system, or the many other back 154 end resources being accessed daily on the Web today? 156 Cohen et. al. claim that outbound print messages are a security risk. 157 But so is outgoing email, ftp, and for that matter, walking out of 158 the door with a briefcase full of confidential materials. The 159 purpose of PFBs is to protect my internal computing resources from 160 malicious attacks, not protect people from walking out of the door 161 with confidential material. We submit that few administrators would 162 care to preent print requests from originating inside the PFB from 163 reaching external serers. Cohen et. al.'s proposal would optimize 164 IPP for those few at the expense of the many. Gien that IPP uses an 165 HTTP content header to proide secondary information about what's in 166 the POST, an adminsitrator who really wants to filter based on 167 content can do so. Perhaps this is a moot point in light of Cohen 168 et. al.'s generic PUSH method where the PFB would also hae to 169 inspect some secondary fields in the HTTP request. 171 Conclusion 173 One of the major reasons the IPP working group decided to use POST 174 was that it allowed us to ery quickly deploy the protocol. By using 175 this "uniform method" for passing blocks of data through a Web 176 serer, and by the way through Proxy/Firewall Boundaries, 177 we hae no dependencies on Web servers and PFBs having to be replaced 178 or upgraded to support printing. We beliee this very significant 179 benefit should not be cast aside lightly. Other applications can and 180 do use it. Cohen et. al. claim that new protocols should not hae 181 to accept a lower leel of security to support a "small" installed 182 base of non-supportie PFBs. I guess if I were a PFB vendor I'd be 183 pleased with eery opportunity to sell an upgraded product, but I'd 184 like Cohen et. al. to explain their position to a customer who has to 185 upgrade his network just to print! 187 In conclusion, we claim that with the current design of HTTP, new 188 capabilities can be added without sacrificing the leels of security 189 that customers expect. Indeed, this capability is being used to 190 delier mission critical applications to the Web every day, without 191 requiring customers to replace the installed base of Web serers or 192 PFBs. Perhaps we could redesign HTTP to be more architecturally 193 pure in this regard, although this is arguable. But een if we could, 194 why would we spend the time to fix something that is not broken, only 195 to require customers to buy the new ersion in order to do something 196 that they can do today? 198 Security Considerations 200 This document proides clarification on security considerations in 201 the use of HTTP. As such, it does not, in of itself, introduce new 202 security considerations. 204 IANA Considerations 206 This document introduces no new IANA considerations. 208 References 210 [1] J. Cohen, A. Hopmann, Y.Y. Goland, V. Valloppillil, P. Leach, and 211 S. Lawrence, "Don't go Postal: An argument against improperly 212 oerloading the HTTP POST Method" Internet Draft, work-in-progress, 213 February 1998 215 [2] A. Rubin, D. Geer, and M. Ranum, "Web Security Sourcebook" 216 John Wiley and Sons, 1997 218 [3] R. Herriot, S. Butler, P. Moore, and R. Turner, "Internet 219 Printing Protocol/1.0: Protocol Specification", Internet Draft, 220 work-in-progress, January 1998. 222 [3] N. Freed and N. Borenstein, "Multipurpose Internet Mail 223 Extensions (MIME) Part Two: Media Types", RFC 2046, Noember 1996 225 [4] D. Connolly, H. Nielsen, R. Khare, Eric Prud'hommeaux, "PEP - 226 an Extension Mechanism for HTTP", Internet Draft, work-in-progress, 227 December 1997 229 Authors Addresses 231 Roger deBry 232 Carl Kugler 233 Harry Lewis 234 Stee Gebert 235 IBM Corporation 236 P.O. box 1900 237 Boulder, CO 80301-9191 238 (email rdebry, harryl, sgebert, kugler @us.ibm.com) 240 Don Wright 241 Lexmark International 242 740 New Circle Rc. 243 Lexington, KY 40550 244 (email don@lexmark.com 245 Scott Isaacson 246 Noell, Inc. 247 122 E. 1700 So. 248 Proo, Utah 84606 249 (email sisaacson@noell.com) 251 Tom Hastings 252 Xerox Corporation 253 701 S. Aiation Blvd. 254 El Segundo, CA 90245 255 (email hasting@cp10.es.xerox.com)