On 19 Apr 2009, at 16:24, Robin Berjon wrote:
On Apr 16, 2009, at 17:23 , Thomas Roessler wrote:
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.
My understanding is that this is like the feature element and
others: it is metadata and its enforcement depends on a security
policy. When that security policy intervenes (I would expect at
runtime, for every access) is presumably orthogonal.
The security policy is likely to intervene at two different times:
1. Install time, when it might turn into a request to the user to
grant the requisite privileges.
2. Run time, when it will at the very least be enforced. (Or might
cause user interactions...)
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 think that this is also meant to be orthogonal to firewalls, but
maybe I'm missing something?
Of course it's orthogonal to firewalls. However, it's not orthogonal
to looking at the side effects that the design here might have on
deployments.
If a particular design for the <access/> element is likely to cause a
larger attack surface, then that's a consideration that needs to go
into the design of <access/>. I'm claiming that the implicit
subdomain model has that effect.
