Re: RFC 3205 background (HTTPSubstrate-16)

> [...]
> ] Addressing these in bullet item order, the definitions of "traditional
> ] HTTP service" and  "new service" are not clear.  It is very difficult to
> ] characterize HTTP traffic in a meaningful way since every URI is
> ] potentially a "new service" in some fashion. Using the dataset referenced
> ] doesn't follow the spirit of the World Wide Web and resources of many
> ] types can co-exist in similar URI namespaces.

The reason for the data-set rationale is that each server process forms a kind
of trust boundary - it has permissions granted to it by the operating system, 
which affect the data (files) that the server can access.   Also, typically 
only one process can be listening for incoming connections on any particular
port.  when there is a need for different services to access different sets 
of data which require different permissions, it is often easier and more
secure to implement those services on separate server processes (and this 
implies separate ports) than to expect one process to securely implement all 
of those services without leaking information between one service and other.
With the latter approach, the compromise of a single server potentially 
compromises all of the data that can be accessed by any of those services.
Also, on many systems there is no way to say "process X has permission
to access files owned by user A, B, C, F, H, Q, and Z" - either process X
has permission to access files of one user, or those of all users.

So it may be that the granularity of permissions on most operating systems 
doesn't "follow the spirit of the World Wide Web" but this language in
3205 was just trying to reflect that reality.  I don't think the web
architecture should constrain people to put each permission domain on a 
separate host, or to assign multiple IP addresses per host, just so they 
can use port 80 for everything.  People can do that if they wish, of course,
but I don't think the architecture should insist on it.  And there's no 
way I'm going to recommend that people run their web servers as root.

> ] Utilization of dedicated ports to filter services on the Web
> ] would not address all security issues and would be expensive in terms of
> ] number of ports in use and enterprise support requirements.  

Certainly true, and I've never claimed that it would.  Ports are only
a crude tool. They're not even close to a complete security solution, 
but they can make the other aspects of the solution more manageable.

> ] Significant
> ] reconfiguration of enterprise infrastructure and additional implementation
> ] and support costs may be avoidable if a layered approach can be used to
> ] meet security, filtering and support requirements.  Furthermore, it is not
> ] clear how allocating new port numbers is consistent with the desire for
> ] limiting use of new port numbers as has been seen in the case of SSL.

The SSL problem has only a tiny bit to do with port exhaustion and more 
to do with "downgrading" - the practice of (for some protocols) trying
SSL first, and if that fails, trying the non-SSL port.  and the problem is
that this is easy to attack and provides a false sense of security. 
(admittedly, in-band negotiation of SSL only raises the bar a little bit)
in general, opportunistic encryption is very hard to do, but that doesn't
prevent people from trying naive approaches to it.

> ] While we do not support the specification of bindings to HTTP for the
> ] purpose of circumventing firewall policies, if a protocol uses the
> ] documented application semantics and extensibility features of HTTP 1.1,
> ] it should not be discouraged from using port 80.

I have to disagree with the last statement - for reasons recently stated, 
there are often good reasons to discourage dissimilar services from all
using port 80. 
 
> Also, I for one would be interested in your response to our comments, if
> you could find them.  I don't know if the TAG would or not.

I'll see if I can dig them up.

Keith

Received on Friday, 5 April 2002 12:05:08 UTC