Re: Benjamin Kaduk's Yes on draft-ietf-httpbis-bcp56bis-14: (with COMMENT)

Hi Ben,

Thanks for the feedback. I've responded and tracked the resulting changes in:
https://github.com/httpwg/http-extensions/issues/1617

Happy to discuss further here or there if necessary.

Cheers,


> On 25 Aug 2021, at 12:51 pm, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-httpbis-bcp56bis-14: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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?
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 25 August 2021 04:38:52 UTC