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

I guess keeping discussion in github is okay.

See
https://github.com/httpwg/http-extensions/issues/1617#issuecomment-909392198
and https://github.com/httpwg/http-extensions/issues/1626

-Ben

On Wed, Aug 25, 2021 at 02:38:29PM +1000, Mark Nottingham wrote:
> 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 Tuesday, 31 August 2021 16:49:49 UTC