Re: [art] Against BCP 190

[Phillip Hallam-Baker <[e-mail]>]

I see two separate problems here with relative paths

1) The path is an extension {whatever}/foo/bar
2) The path climbs the tree {whatever} = ../fred

The problem dealing with the second is that you end up with security issues
that affect ZIP files every five years as the code is re-implemented by a
new person who makes the old mistake. So unzipping a zip archive ends up
overwriting the hosts file or whatever and allows the machine to be rooted.

I see no problem with {whatever}/foo/bar if whatever is a simple prefix.
But it is not an approach to Web Service design I find particularly useful
any more. Unless a Web service is genuinely a data retrieval problem, it is
not going to use HTTP for anything more than expanding the effective number
of ports on the machine and punching a hole in the firewall. Both are
necessary and useful. But they use about 5% of the capabilities of HTTP if
that.

My view therefore is that as TLS everywhere and QUIC take over, we should
look forward to being able to specify a new UDP based transport for 'Web
Service' binding that is designed to meet the needs of Web services and
nothing else. The firewall bypass to be provided by TLS/QUIC. So all we
need to provide at the 'Web Service' layer is a means of disambiguating the
sub-service protocol.

So where I expect we will end up in 5-10 years time is that 'Web Services'
run over a different transport where the interaction looks something like

Client: <well-known> <length> <binary data>
Service: <length> <binary data>
Client: <length> <binary data>

Etc...

Since this would just be using the protocol multiplexing and data framing
capabilities of HTTP, it can be a lot simpler than HTTP. We don't want to
cache in the network (which hasn't worked since SSL) and we certainly don't
want content negotiation.

I don't like REST because I don't find URIs a useful data encoding and see
no value in splitting the request semantics between the URI path and the
POST body. Just do it all in JSON, stick it all in the body and then you
have a simple way to wrap it with a signature or an application level keyed
MAC if you need it.

So that is where I think we should try to head. Just make the traffic look
as nearly like TLS as allows firewall traversal and make sure that legacy
clients and services can downgrade to HTTP.

Web Services require almost none of the functionality of HTTP/1.1 so I see
no reason they would benefit from HTTP/2.


On Fri, Jul 12, 2019 at 12:45 PM Rob Stradling <[e-mail]> wrote:

> During IESG review of RFC6962-bis (Certificate Transparency Version
> 2.0), BCP 190 is creating significant problems in standardizing
> HTTP-based APIs.  Specifically, this paragraph of section 2.3
> (https://tools.ietf.org/html/bcp190#section-2.3)
>
>     Specifying a fixed path relative to another (e.g., {whatever}/myapp)
>     is also bad practice (even if "whatever" is discovered as suggested
>     in Section 3); while doing so might prevent collisions, it does not
>     avoid the potential for operational difficulties (for example, an
>     implementation that prefers to use query processing instead, because
>     of implementation constraints).
>
> This paragraph should be struck.  It is out of date, since all modern
> web servers can trivially rewrite paths to query components and back
> again.  It also encourages inserting levels of indirection that add
> complexity and bugs.
>
> In RFC6962, all paths are specified relative to a "log server" prefix
> that can contain a path as well as a server name and a port:
>
>    POST https://<log server>/ct/v1/add-chain
>    GET https://<log server>/ct/v1/get-sth
>    GET https://<log server>/ct/v1/get-entries?start=1000&end=2000
>    … 5 more request types defined similarly ...
>
> This version of CT, which preceded BCP 190, has been in production use
> for several years, with multiple independent implementers on both the
> server side and the client side.  There have been no complaints that
> specifying paths in these ways is at all difficult or interferes with
> operation of other software.
>
> A similar problem arose during ACME standardization.  At first it was
> solved by defining a "straight through" issuance path where each step
> provided a URL for the next step.  This was abandoned because there are
> plenty of issuance cases that are not straight-through - for instance,
> revocation.  Now ACME indirects all requests through a "directory" JSON
> object that maps, e.g. "newAuthz" to "https://example.com/newAuthz".
> This works moderately well, but adds complexity, increases the total
> number of requests, and as it turns out, may have bugs
> (https://www.rfc-editor.org/errata_search.php?eid=5771)
>
> For 6962-bis, the TRANS WG has cycled through three different attempts
> to work around BCP 190: a .well-known path prefixing all the paths
> defined by the API, a directory, and treating the entire set of request
> types as parameters to a log definition delivered out of band.  All were
> found to be unsatisfactory.  The affected URI owners (log operators) are
> being prevented by BCP 190 from doing what they would prefer to do with
> their URI space, which is to use URIs constructed in the same manner as
> RFC6962 (with "/ct/v1" changed to "/ct/v2").
>
> BCP 190 is standing in the way of standardizing simple, sensible HTTP
> APIs and should be amended.
>
> Thanks,
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>