On Sat, Jan 30, 2016 at 9:50 PM, Mark Nottingham <mnot@xxxxxxxx> wrote: > There's an important point under all of this. > > On 23 Jan 2016, at 2:55 am, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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.