On Sat, Jan 30, 2016 at 9:50 PM, Mark Nottingham <mnot(_at_)mnot(_dot_)net>
wrote:
There's an important point under all of this.
On 23 Jan 2016, at 2:55 am, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com> wrote:
Alice is the administrator of the system, she is running a Web Server
for the company on http://example.com/ with a redirect mapping from
http://www.example.com/*
Bob wants to setup an XXX service which is a Web Service with a HTTP
binding. Alice will let him run that service but does not want to
grant unrestricted access to the corporate Web service on port 80/443.
How do we support that?
It's exceedingly difficult. The Web has for some time set most meaningful
security boundaries at the origin level -- i.e., (scheme, host, port).
Allowing Bob access to <https://www.example.com/.well-known/bob> still gives
him a considerable amount of leeway to content and capability on other parts
of the origin, including:
* reading and writing cookies
* reading and writing LocalStorage
* setting ServiceWorkers to intercept requests and synthesise responses for
the whole host
* access to use and set permissions for capabilities like camera access,
microphone access, geolocation
* provide content -- including active content (e.g,. JavaScript) -- for
execution with escalated privilege
* ability to set origin policy such as CSP, HSTS, etc.
This is a small, incomplete sample. Alice can try to limit Bob's capabilities
by controlling the headers and content that he sets, but that's probably a
losing battle; it requires her to keep up with every development in the Web
platform, and code her containment perfectly.
The takeaway here is that .well-known is *not* a sandbox to put content into,
and treating it like that can have serious security implications.
.well-known certainly isn't a sandbox. It is more like having Chinese
Walls. In a corporate environment I am interested in two separate
problems:
* Incompetence
* Malice
Unintended consequences are just as consequential as intended. So
having mechanisms that provide separation provided the parties don't
actively attack is 'good enough' for most purposes. That is pretty
much what most O/S security gives you anyway.
This is certainly an area where I would want to improve on in the
medium to long term. Which is why I don't expect to be using HTTP as a
Web Services transport past the medium term except for legacy. HTTP/2
is optimized for Web Browsing which is a perfectly sensible thing to
do. HTTP/2 doesn't actually provide much I find very useful in a
secure Web Service and a lot that gets in the way.
Which is of course why I want consistency between .well-known and SRV
records. If I have a client that supports either the legacy
.well-known HTTP binding or some new binding over Web Sockets, I want
to be able to use the same vocabulary of terms for both. I don't want
to call my protocol _sparklepony at the SRV level, SpecialSnowflake
for .wellknown and SparklePoni for whatever new scheme is developed.
Yes, I am fully aware that Web Services is not something that a lot of
people in the HTTP world seem to care about. The term 'anti-pattern'
was used. Well I certainly won't argue that running every protocol
over ports 80 and 443 is a design of choice but we ended up in this
situation for a number of historical reasons that won't go away
immediately. But one of those reasons was that there wasn't another
well supported port mux protocol.
The reason I want to clarify existing practice is precisely to enable
new innovation. That might be Web Sockets based or it may be TAPS or
perhaps it is both.
Anyone who has written crypto code is familiar with the problems that
arise from the use of separate identifiers to refer to the same
algorithms in ASN.1, PEM and XML Signature (and now JOSE). This
despite the fact that these are nominally all extensible code spaces
(use of a restricted code space as OpenPGP, IPSEC, DNSSEC and TLS
forces the use of a separate registry of course but that is another
issue and there is actually an argument for restrictive registries at
the lower protocol layers.)
I am not planning to innovate in this space myself but I do want to be
a consumer of whatever innovations are proposed. But I can't see that
happening if every new transport renames all the services.
The governing principle at the application layer should be
permissionless innovation. I see a series of separate issues:
1) How should the decision to determine the registration criteria for
protocol registries be made? Should this be left to the Working Group
that develops a platform or is this an area that should be guided by
IETF level policy from the IAB?
2) Should .well-known be a separate registry from Ports and Services?
3) If the registry is separate, should the registry require
publication of a specification as is the case today?
On point 1 we have a classic tension between the desire for coherence
across IETF specifications and the desire for bottom up consensus
based decision making. The reason I think this is a decision that
should be strongly influenced by IAB rather than the HTTPbis working
group is that this is a decision that affects other groups outside
HTTPbis. In fact this is a decision that will by its nature ONLY
affect groups outside the original working group.
We can argue the second but I will point out that there isn't much
difference between .well-known and .well-known/srv being 'first come'.
Back in the day someone wanted every HTTP protocol URI to be prefixed
with url:
I think the answer to the third is clear if we apply the principle of
permissionless innovation. Specification Required is too high a bar.
This registry should be first come first served.