Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-15
Yes
Francesca Palombini
No Objection
Zaheduzzaman Sarker
(Alvaro Retana)
(Martin Vigoureux)
Note: This ballot was opened for revision 13 and is now closed.
Erik Kline
Yes
Comment
(2021-08-18 for -14)
Sent
[S4.3, comment] * Are all the uses of "should" here deliberately lowercase? I got the feeling some of them could well have been SHOULD, e.g., "Applications using HTTP SHOULD specify that ... when HTTPS is used." [S4.5.1, nit] * s/ought consider/ought to consider/, I suspect [S4.5.2, question] * Is it correct to say "OPTIONS is not the default GET method"? Should that be something like "not the default HTTP method"? [S4.10, question] * Might "ambient authority" benefit from a reference to RFC 6454 section 8.3? [S4.13, nit] * "can execute script" -> "a script" or "scripts"?
Francesca Palombini
Yes
Murray Kucherawy
Yes
Comment
(2021-08-26 for -14)
Sent for earlier
Nice work once again. Questions (1) and (7) of the shepherd writeup weren't properly answered. IMHO, I suggest dropping Appendix A. Indicating (as you have) that this document replaces RFC 3205 is sufficient.
Roman Danyliw
No Objection
Comment
(2021-08-23 for -14)
Sent
Thank you to Joseph Salowey for the SECDIR review. ** Section 4.5 and 4.6. ... they are encouraged to engage with the HTTP community early, and document their proposal as a separate HTTP extension, rather than as part of an application's specification. Can more specificity be provided on who this “HTTP community” might be? Is this consulting whatever is the active WG maintaining HTTP in the IETF? The implementation community of HTTP libraries or browsers? ** Section 6. If the transport is unencrypted, an attacker that can eavesdrop on HTTP communications can often escalate their privilege to perform operations on resources. To me, eavesdrop means just the ability to read the cookie/bearer token. An on-path attacker could also escalate privileges by modifying the cookie. Proposing text just as: NEW If the transport is unencrypted, an attacker that can eavesdrop and/or modify HTTP communications can often escalate their privilege to perform operations on resources. ** Editorial -- Section 3.1. It also allows people to leverage their knowledge of HTTP semantics without special-casing them Consider using alternative wording for “special-casing” -- Section 4.6. Editorial. Missing reference notation. OLD HTTP/2 I-D.ietf-httpbis-http2bis message format. NEW HTTP/2 [I-D.ietf-httpbis-http2bis] message format. -- Section 4.6.1. Editorial. s/can not/cannot/ -- Section 4.9.1 and 4.9.4. Both of these sections have illustrative examples of responses. They are clear. Note that Section 4.1 calls out that “[w]hen specifying examples of protocol interactions, applications should document both the request and response messages, with complete header sections, preferably in HTTP/1.1 format”. It isn’t clear if the guidance for HTTP application (this document) should follow it’s own guidance (since this document isn’t an HTTP application). -- Section 4.11. Editorial. Missing reference notation. OLD HTTP/3 I-D.ietf-quic-http NEW HTTP/3 [I-D.ietf-quic-http]
Warren Kumari
No Objection
Comment
(2021-08-24 for -14)
Not sent
Thank you for this - I found it an interesting and useful read.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment
(2021-08-25 for -14)
Sent
Thank you for the work put into this document, which is also easy and interesting to read. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tommy Pauly for his shepherd's write-up notably about the WG consensus. I hope that this helps to improve the document, Regards, -éric -- Section 2 -- I am puzzled by the wording " The requirements in this document" in this BCP... Should it rather be "The applicability of this document..." ? The following bullet list is unclear whether it is a "OR" or a "AND". -- Section 3.2 -- s/Another common practice/Another common mistake/ ? Some examples would be welcome as well. -- Section 4.4.2 -- Isn't the reference to RFC 7258 redundant in ""https" is RECOMMENDED to provide authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks [RFC7258]." ? -- Section 4.5 -- In "they are required to be registered" should normative "REQUIRED" be used ? Also, possibly naively, surprised by the absence of the "POST" method in the list of detailed methods.
Benjamin Kaduk Former IESG member
Yes
Yes
(2021-08-24 for -14)
Sent
Thanks to Tommy for the shepherd writeup, which was very nice except that it only answered one of the three parts of question (1). Thanks once again to the editors and WG for another very well-written document! Thanks as well to Joe Salowey for the secdir review, and to the authors for the discussion and updates in response to it. I made a github pull request with a few editorial suggestions: https://github.com/httpwg/http-extensions/pull/1616 Section 3.2 As explained in [RFC8820], such "squatting" on a part of the URL Are there toolchain issues that prevent BCP190 from being the reference here or is there some other reason to prefer the RFC form of the reference? Section 4.3 It seems somewhat surprising that the things we say about client behavior are basically unrelated to the areas where we ask for server behaviors to be specified. Is there anything useful to say about, e.g., how the client uses media types, handles header fields, and processes link relationships (even if [FETCH] would also say such things)? Section 4.4.2 Applications that use HTTP will typically employ the "http" and/or "https" URI schemes. "https" is RECOMMENDED to provide authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks [RFC7258]. It seems clear to me that use of "https" is both IETF current practice and a general best practice. I see the shepherd writeup's mention of the extensive WG discussions on this guidance (regarding "RECOMMENDED" vs "MUST"), and posit that the lack of a clear definition of what BCP 14 keywords mean in a BCP-status document (and perhaps some lack of clarity as to what the scope of applicability of this document is) underlie much of the controversy. (We saw a similar controversy in what became RFC 8996 (part of BCP 195) and its various "MUST NOT"s.) In light of the extensive WG discussion that already occurred, I do not see reason to ballot DISCUSS on this topic, but do ask if avoiding BCP 14 keywords entirely was considered, along the lines of: % The use of TLS, i.e., the "https" URI scheme, is the best current % practice, since it provides (source) authentication, integrity and % confidentiality, as well as mitigation against pervasive monitoring % attacks [RFC7258]. * The resources identified by the new scheme will still be available using "http" and/or "https" URLs. [...] Is this availability guaranteed, or just a common risk ("likely")? I could imagine a custom HTTP implementation that only allows requests using a single (custom) scheme, though admittedly mostly just as a thought experiment and not something practical. Section 4.6.1 An application using HTTP should specify if any request header fields that it defines need to be modified or removed upon a redirect; however, this behaviour cannot be relied upon, since a generic client (like a browser) will be unaware of such requirements. Should we encourage the application designer to use "fail safe" semantics for such request header fields in light of the non-guarantee that application-specific requirements will be heeded? (Possibly in a later section more focused on header fields or application state rather than here.) Section 4.9.1 It is not necessary to add the public response directive ([I-D.ietf-httpbis-cache], Section 5.2.2.9) to cache most responses; it is only necessary when it's desirable to store an authenticated response. This seems to be a slightly different definition than the referenced document uses. I am not entirely sure whether the divergence is actually problematic, though. Section 4.12 Applications can use HTTP authentication Section 11 of [I-D.ietf-httpbis-semantics] to identify clients. As per [RFC7617], the Basic authentication scheme is not suitable for protecting sensitive or valuable information unless the channel is secure (e.g., using the "HTTPS" URI scheme). Likewise, [RFC7616] requires the Digest authentication scheme to be used over a secure channel. I see that this text has already been subject to quite a bit of discussion, but RFC 7616 doesn't "require" this; it says that "it SHOULD be over a secure channel like HTTPS". If pressed to suggest an alternate phrasing, I would offer "[RFC7616] expects the Digest authentication scheme to be used over a secure channel", but I am not specifically promoting that phrasing. With HTTPS, clients might also be authenticated using certificates [RFC5246]. When used, it is important to carefully specify the scoping and use of authentication; if the application exposes sensitive data or capabilities (e.g., by acting as an ambient authority), exploits are possible. Mitigations include using a request-specific token to assure the intent of the client. To mention client certificate authentication and scoping of authentication in such close proximity but not discuss the well-known pitfalls of TLS client certificate authentication feels like it's leaving a big gap open. I think we want to add something roughly like: % TLS client certificate authentication is intrinsically scoped to the % underlying transport connection. On such an authenticated connection, % a client has no way of knowing whether the authenticated status was % used in preparing the response (though "Vary: *" can provide a partial % indication), and the only way to obtain a specifically unauthenticated % response is to open a new connection. Applications should consider % whether or not client certificate authentication is appropriate for % their needs and expected use patterns. TLS Exported authenticators % [I-D.ietf-tls-exported-authenticator] are an attempt to remove some of % these limitations while retaining the convenience and other advantages % of client certificate authentication. (The last sentence is optional, of course.) Section 6 Do we want to incorporate by reference the security considerations of any other documents? -semantics, -cache, and RFC 8288, perhaps? ("Application protocols using HTTP are subject to the security considerations of HTTP itself and any extensions used; [I-D.ietf-httpbis-semantics], [I-D.ietf-httpbis-cache], and [RFC8288] are some often-relevant references.") If not, there might be a few things worth mentioning as standalone, e.g., risk of infinite redirect loops and the scope of issues possible when Vary: isn't used. The potential for skew between HTTP caching and (distinct) application protocol lifetime values discussed in §4.9.3 is a likely source of security issues, so that section might merit a mention in this listing. Section 7.1 It's not entirely clear to me that RFC 7301 needs to be listed as normative; we mention ALPN only in the context of (paraphrasing) "applications using HTTP ALPN values are subject to these requirements". Section 7.2 We reference httpbis-cache in a number of places, and the sentiment in several seems to be along the lines of "applications really ought to consider the potential impact of caches, since caches might appear in the request path for reasons outside the control of the application". Classifying it as a normative reference seems like it would be defensible (though leaving it as informative is also defensible). NITS Section 1 This document contains best current practices for the specification of such applications. [...] Earlier we've talked about "applications other than Web browsing", "protocols [that] are often ad hoc", "applications [with] multiple, separate implementations", and "application protocol[s] using HTTP". When we say "such applications" do we have a specific referent in mind? Section 4.5.1 Therefore, applications using HTTP that feel a need to allow POST queries ought consider allowing both methods. All the "ought"s in -semantics made sense, but seeing as this document is a BCP, maybe it's okay to give a more definitive recommendation? Section 4.9.3 One way to address this is to explicitly specify that all responses be fresh upon use. I think I'm failing to parse this sentence properly, and it's unclear if s/be/are/ is the right fix. (In particular, what does it mean to "use" a response?) Section 4.16 In HTTP, backwards-incompatible changes are possible using a number of mechanisms: "A number of" implies uncertainty about exactly how many, which would typically be accompanied by "including"; if the list is actually exhaustive, using the actual number ("three") might be preferred. Section 6 We refer to several other sections as being security-relevant, and the list is almost (but not) sorted. Should it be sorted?
Martin Duke Former IESG member
Yes
Yes
(2021-08-17 for -13)
Sent
Thanks for this update. One tiny comment, to which I don't need a response: The discussion about links in Sec 3.2 could use a reference to RFC 8288.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -14)
Not sent
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2021-08-24 for -14)
Sent for earlier
Section 2. , paragraph 5, comment: > * uses an ALPN protocol ID [RFC7301] that generically identifies > HTTP (e.g., "http/1.1", "h2", "h2c"), or Might want to mention "h3" as part of the examples. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1. , paragraph 4, nit: > ric/application-specific split allows a HTTP message to be handled by common > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". (Also elsewhere.) Section 4. , paragraph 2, nit: > mple, HTTP/2's multiplexing), this ought be noted. Applications using HTTP MU > ^^^^^^^^ Did you mean "ought to be"? Section 4.4.1. , paragraph 6, nit: > s can also be defined. When defining an URI scheme for an application using H > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 4.4.2. , paragraph 2, nit: > uests don't get sent to a "normal" Web site is likely to fail. * Features th > ^^^^^^^^ Nowadays, it's more common to write this as one word. (Also elsewhere.) Section 4.4.3. , paragraph 2, nit: > trieval semantics allow caching, side-effect free linking and underlies many > ^^^^^^^^^^^ Did you mean "side effect" (=adverse effect, unintended consequence)? Open compounds are not hyphenated. Section 4.5. , paragraph 3, nit: > nt; doing so avoids encoding overhead and URL length limits in implementation > ^^^^ Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). Section 4.5. , paragraph 4, nit: > el a need to allow POST queries ought consider allowing both methods. Applica > ^^^^^^^^^^^^^^ Did you mean "ought to consider"? Section 7.2. , paragraph 9, nit: > Best Current Practice in the early 2000's, based on the concerns facing prot > ^^^^^^ Apostrophes aren't needed for decades. Document references draft-ietf-httpbis-messaging-17, but -18 is the latest available revision. Obsolete reference to RFC5246, obsoleted by RFC8446 (this may be on purpose). These URLs in the document can probably be converted to HTTPS: * http://httpwg.github.io/
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -14)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2021-08-20 for -14)
Sent
Hi Mark, Thanks for this document, I found it to be a very interesting read, and I can see that this will be useful to refer to in future. A few minor comments: Sec 4.4.2: "However, application-specific schemes can also be defined" Given the previous paragraph is using 2119 language, I think that "MAY" would be better than "can also" here. Sec 4.5.1: Suggest changing "to have content" to "to contain content". I had to read this a couple of times to understand that this was about the GET request sending content to the server rather than content in the response. Sec 4.13: Nit: Suggest changing "consider the application actually" => "actually consider the application" Sec: 6.1. Privacy Considerations "to run mobile code" I think that it would be helpful to expand on what you mean by "to run mobile code". I.e., I presume this is about allowing a client to send code that is executed on the server, rather than the concern being about applications that run on mobile/cell devices. ;-) Regards, Rob