Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-15

Note: This ballot was opened for revision 13 and is now closed.

Benjamin Kaduk Yes

Comment (2021-08-24 for -14)
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?

Erik Kline Yes

Comment (2021-08-18 for -14)
[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

Martin Duke Yes

Comment (2021-08-17 for -13)
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.

Murray Kucherawy Yes

Comment (2021-08-26 for -14)
No email
send info
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.

Alvaro Retana No Objection

Lars Eggert (was Discuss) No Objection

Comment (2021-08-24 for -14)
No email
send info
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 No Objection

Robert Wilton No Objection

Comment (2021-08-20 for -14)
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

Roman Danyliw No Objection

Comment (2021-08-23 for -14)
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)
No email
send info
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)
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.