Re: [ac] wildcard rules and subdomains

I don't want to get into arguing about uptake either. A more important 
point is however that for the p3p spec err on the side of including 
fewer sites than expected is ok. The place where I see the syntax we're 
using is used is section 2.3.2.6 of the p3p 1.0 spec. If the author 
misses to add example.com in addition to *.example.com there will be no 
security issues.

This is not the case in our spec, if the author misses adding example.com to
Content-Access-Control: deny <*.evil.com>
very bad things can happen.

An alternative solution is to remove the wildcard syntax entierly, and 
say that it's implicitly always there. So

Content-Access-Control: deny <evil.com>, allow <good.com>

denies evil.com together with subdomains, while allowing good.com 
together with subdomains.

/ Jonas

Mark Nottingham wrote:
> 
> The P3P folks would disagree with your characterisation of uptake (e.g., 
> <http://lorrie.cranor.org/pubs/icec06.pdf>). I'm staying out of it :)
> 
> 
> On 2007/07/04, at 12:45 PM, Jonas Sicking wrote:
> 
>>
>> Ah, that makes sence. Though given the very poor uptake of p3p I don't 
>> think that parity with it is very important. I'd prefer to do what is 
>> safest and easiest to use.
>>
>> / Jonas
>>
>> Mark Nottingham wrote:
>>> IIRC (and I could be remembering wrongly), it was done this way to 
>>> align with how p3p.xml, etc. work, so there wouldn't be multiple, 
>>> almost-the-same-but-conflicting standards out there.
>>> Cheers,
>>> On 2007/07/04, at 10:35 AM, Jonas Sicking wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Currently the spec says that a rule like "*.example.com" does not 
>>>> match a request from example.com. The result is that if you want to 
>>>> give access to anything coming from example.com, including any 
>>>> subdomains, you'll have to write a rule like:
>>>>
>>>> Content-Access-Control: allow <*.example.com>, <example.com>
>>>>
>>>> And similarly, if you want to deny requests from evil.com you have 
>>>> to do:
>>>>
>>>> Content-Access-Control: deny <*.evil.com>, <evil.com>
>>>>
>>>> I think it would be better if *.example.com also matched example.com.
>>>>
>>>> Pros:
>>>> In many cases you can write simpler rules since I'd imagine it's 
>>>> more likely that you want to deny or grant access to both a domain 
>>>> and its subdomains, than that you just want one of the two.
>>>>
>>>> There's no longer a risk that someone will think that *.example.com 
>>>> does match example.com.
>>>>
>>>> Cons:
>>>> There's a risk that someone will think that *.example.com does not 
>>>> match example.com.
>>>>
>>>> I actually think that the consequences of misunderstanding is 
>>>> smaller in the latter case. Lets example the possible 
>>>> misunderstandings under the two algorithms:
>>>>
>>>>
>>>> == Current algorithm, *.example.com does not match example.com ==
>>>> Author uses the rule
>>>> Content-Access-Control: allow <*.example.com>
>>>> and thinks this grants access to example.com
>>>>
>>>> The consequences aren't very bad, the only thing that will happen is 
>>>> that when the site example.com is used things will not work. This is 
>>>> easily detectable and fixed
>>>>
>>>> Author uses the rule
>>>> Content-Access-Control: deny <*.example.com>
>>>> and thinks this denies access to example.com
>>>>
>>>> The consequences are bad. Access is not denied to example.com even 
>>>> though that was intended.
>>>>
>>>> == Proposed algorithm, *.example.com does match example.com ==
>>>> Author uses the rule
>>>> Content-Access-Control: allow <*.example.com>
>>>> and thinks this does not grant access to example.com
>>>>
>>>> The consequences are somewhat bad, access is granted to example.com 
>>>> even though that was not intended. However, it is likely that 
>>>> however runs example.com could simply set up foo.example.com and use 
>>>> that to get access. In general I can't think of a real-world example 
>>>> where you'd trust the subdomains of a site, but not the top domain.
>>>>
>>>> Author uses the rule
>>>> Content-Access-Control: deny <*.example.com>
>>>> and thinks this does not deny access to example.com
>>>>
>>>> The consequences aren't very bad, the only thing that will happen is 
>>>> that when the site example.com is used things will not work. This is 
>>>> easily detectable and fixed.
>>>>
>>>> / Jonas
>>>>
>>> -- 
>>> Mark Nottingham       mnot@yahoo-inc.com
>>
>>
> 
> -- 
> Mark Nottingham       mnot@yahoo-inc.com
> 
>

Received on Thursday, 5 July 2007 22:17:13 UTC