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

[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"?

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.

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?

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.