Re: Simple approach for <access>

Robin wrote:

> The <access> element is used to restrict a widget's access to a
> limited set of network resources. In the absence of an <access>
> element, all access to network resources is forbidden.
>
> The <access> element has a single @href attribute the content of which
> is an IRI-like string. The access opening that is specified by that
> string is defined as follows:
>
>   - the scheme component MUST be present, and access is granted only
> for that scheme; and
>   - the host component MUST be present. If it begins with "*." then
> the host that follows the "*." is granted access to, as well as all of
> its lower-level domains; otherwise access is only granted for that
> domain; and
>   - if the port component is absent, it is considered to be specified
> to be the default for the provided scheme. Access is granted only to
> that port; and
>   - if the path and query string component is present, then access is
> granted for any path and query string that starts with the specified
> string. It is treated as an opaque string, no attempt must be made to
> map to potential directories on the remote server; and
>   - if a fragment component is specified, it must be ignored.

Two questions:

1. How is the information in this access element going to be used at  
installation time or distribution time?  I'd like to see some spec  
text that explains this.

2. If one of the risks we're interested in is firewall traversal, then  
then proposed domain name wildcard has a somewhat different risk  
profile than just a single domain name:  while you can do a DNS  
rebinding attack for a single hostname, that's a well-known issue, and  
hopefully worked around in today's browser engines.  With the  
wildcard, though, it becomes relatively easy to do firewall  
traversal:  For example, one could simply generate DNS records  
n.n.n.n.example.com that point to the IP address n.n.n.n.

I wonder whether it might be useful to clearly distinguish the two  
cases (given the different risk profiles); I'd also like to see some  
discussion of this effect in the security considerations.

Thanks,
--
Thomas Roessler, W3C  <tlr@w3.org>