Re: [secdir] draft-ietf-geopriv-policy-uri-02

[Richard Barnes <[e-mail]>]

>> <trimmed...>
>> Why isn't unauthorized manipulation of the policy information also listed as a risk? Actually, the second paragraph of the security considerations addresses this, ("The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy."), but subsequent text seems to indicate that if the policy URI is not kept secret, there are no further protections.
>> Since we're talking about access control policy here, the effect of "manipulation of the policy information" is precisely "unauthorized disclosure of the protected resource".  Does that clear thing sup?
> 
> I see your point, but manipulation of policy information could also be used to prevent/deny disclosure too. As I noted below, I have no experience with these protocols, and this may not matter, but as a reviewer, I think I should mention it.

That's a fair point.  How about this change to the text:

OLD: "The risk of unauthorized disclosure of the protected resource" 
NEW: "The risk of unauthorized grants or denial of access to the protected resource" 


>>> Am I missing something here, or is secrecy of the URI really the only protection against unauthorized policy manipulation? I have to admit that I have no experience with these protocols, and it may be that this is addressed elsewhere (or truly doesn't matter), but it does feel a bit off.
>> 
>> You're exactly right in that understanding.  The idea is that a policy URI is already controlling access control policy on something, so we didn't want to have access control policies for who can access policy URIs (turtles all the way down).  That's the reason for all the text about keeping the policy URI secret.
> 
> I didn't see any language suggesting that if one wishes to mitigate the resulting exposure, these URIs should probably be short-lived. Is that covered in one of the related docs?  Again, not sure if this matters, but as the boilerplate suggests, the purpose of these secdir reviews is to let the security ADs (who presumably have much more context) know if there's anything they should be aware of, so I pointed it out. Lacking background and protocol expertise, I don't have any strong position of my own on this.

It's sort of covered in that policy URIs have the same lifetime as the underlying location URI, but there's not anything like a "key roll-over" mechanism.  It seems to me like the current limitations are sufficient, but if the ADs feel differently, we can make changes.