Subject: [Geopriv] retransmission-allowed is harmful

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Mar 2009 01:13:00 -0500

I just finished reviewing draft-barnes-geopriv-lo-sec.  I wont get those hours back, but it wasn't all in vain.  There's stuff in there I'd recommend to all members of the group.

A thought arises:

If I set retransmission-allowed = false, all I'm saying is the default.  We knew that already, no gain to be had unless a value of true turns out to be useful.

If I set retransmission-allowed = true, then there are two options:

 (1) the information is totally public - share with the world

 (2) there is an authorization policy that governs redistribution of this information

But that's the thing.  Unless you have a policy, you should be assuming the empty policy - and the empty policy prevents redistribution.

Therefore, you need a policy before you can redistribute location information.  Therefore, the authorization necessary to distribute is signified by the presence of policy.  Absence of policy indicates that you should keep the information to yourself.  Therefore, retransmission-allowed is pointless.  Therefore, it's harmful because recipients might assume (1).

The prosecution rests ma'am.

Cheers,
Martin

p.s. "is harmful" in the subject was chosen to be inflammatory, if you are reading this, I've been successful.  Thank you for your time.

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 09:09:49 +0200

In previous discussions I mentioned that the basic privacy fields do not
provide enough semantic, see for example
http://www.ietf.org/mail-archive/web/geopriv/current/msg06389.html (with
regard to the question of who the recipient actually is). 

You point out another aspect that is not discussed in RFC 4119, namely what
is the relationship between retransmission-allowed and the policies
referenced by the ruleset-reference element. RFC 4119 also does not saw what
the meaning is if the ruleset-reference is empty. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Thomson, Martin
>Sent: 12 March, 2009 08:13
>To: GEOPRIV
>Subject: [Geopriv] retransmission-allowed is harmful
>
>I just finished reviewing draft-barnes-geopriv-lo-sec.  I wont 
>get those hours back, but it wasn't all in vain.  There's 
>stuff in there I'd recommend to all members of the group.
>
>A thought arises:
>
>If I set retransmission-allowed = false, all I'm saying is the 
>default.  We knew that already, no gain to be had unless a 
>value of true turns out to be useful.
>
>But that's the thing.  Unless you have a policy, you should be 
>assuming the empty policy - and the empty policy prevents 
>redistribution.
>
>Therefore, you need a policy before you can redistribute 
>location information.  Therefore, the authorization necessary 
>to distribute is signified by the presence of policy.  Absence 
>of policy indicates that you should keep the information to 
>yourself.  Therefore, retransmission-allowed is pointless.  
>Therefore, it's harmful because recipients might assume (1).
>
>p.s. "is harmful" in the subject was chosen to be 
>inflammatory, if you are reading this, I've been successful.  
>Thank you for your time.
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Mar 2009 12:26:31 -0500

>the meaning is if the ruleset-reference is empty.

RFC 4119 had no concept of routing based on location, I believe, 
therefore the only viable LR was the destination LR, and not an 
intermediary in between the LG and LR.

This is why the careful idea (which doesn't need to be overblown, 
mind you) that any intermediary *may be* (not *is*) a potential LR.

We need to address those intermediaries that are in fact capable of 
being an LR (i.e., not all SIP proxies have this ability, btw), then 
write security concerns (or considerations) for that instance. We 
should not assume everything that receives the packet that contains 
LI is an LR, because that would include all routers and L2 
switches... and we simply do not need to account for them.

BTW - I feel that retransmission-allowed=true means #1 below must be 
assumed unless the Location inserter (LG, which is either the UAC or 
SIP Proxy - using the SIP model for context) *knows* there is policy 
in place.  This is based on assumptions, and in security, one cannot 
assume something to be in place unless one knows it is in place - 
therefore "=true" means totally public.

lo-sec needs to flesh out the different cases IMO

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Mar 2009 16:44:30 -0500

I also had other thoughts overnight.  Retransmission-allowed (or something to that effect) is actually helpful on location URIs.  I've made the point previously, but for what it's worth:

Any indication would need to appear in the conveyance protocol associated with the location URI.  A default of "no" needs to be assumed.  A value of "yes" indicates that the rule maker is confident that the LS serving the location URI is able to effectively enforce rules.  Without such an indication, "no" is the only permissible interpretation an LR can make.

Ta,
Martin

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, 12 March 2009 6:10 PM
> To: Thomson, Martin; 'GEOPRIV'
> Subject: RE: [Geopriv] retransmission-allowed is harmful
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Mar 2009 20:22:48 +0200

Two points: 

A) I guess nobody really thought sufficiently deep enough about conveying
the policies in the style of http://www.ietf.org/rfc/rfc4745.txt /
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-20.txt
together with location information. I suspect that folks say it more as a
vehicle for access control and hence it wouldn't travel around. 

B) In a location URI there is no policy that travels with it (as it is
currently defined). One could, of course, define a URI in the style of
http://tools.ietf.org/html/rfc4467 and attach meta data. We discussed this
several times already but, as far as I remember, never made a decision. It
wouldn't really change anything with the location URI concept as such but
the entity that looks at it would have a clue what the URI actually is. This
would then go into the
http://tools.ietf.org/id/draft-winterbottom-geopriv-held-context-03.txt
document. 

Ciao
Hannes

>I also had other thoughts overnight.  Retransmission-allowed 
>(or something to that effect) is actually helpful on location 
>URIs.  I've made the point previously, but for what it's worth:
>
>Any indication would need to appear in the conveyance protocol 
>associated with the location URI.  A default of "no" needs to 
>be assumed.  A value of "yes" indicates that the rule maker is 
>confident that the LS serving the location URI is able to 
>effectively enforce rules.  Without such an indication, "no" 
>is the only permissible interpretation an LR can make.
>
>Ta,
>Martin
>
>> In previous discussions I mentioned that the basic privacy fields do 
>> not provide enough semantic, see for example 
>> You point out another aspect that is not discussed in RFC 
>4119, namely 
>> what is the relationship between retransmission-allowed and the 
>> policies referenced by the ruleset-reference element. RFC 4119 also 
>> does not saw what the meaning is if the ruleset-reference is empty.
>> 
>> Ciao
>> Hannes
>> 
>> >I just finished reviewing draft-barnes-geopriv-lo-sec.  I wont get 
>> >those hours back, but it wasn't all in vain.  There's stuff 
>in there 
>> >I'd recommend to all members of the group.
>> >
>> >A thought arises:
>> >
>> >default.  We knew that already, no gain to be had unless a value of 
>> >true turns out to be useful.
>> >
>> > (2) there is an authorization policy that governs 
>redistribution of 
>> >this information
>> >
>> >Therefore, you need a policy before you can redistribute location 
>> >information.  Therefore, the authorization necessary to 
>distribute is 
>> >signified by the presence of policy.  Absence of policy indicates 
>> >that you should keep the information to yourself.  Therefore, 
>> >retransmission-allowed is pointless.
>> >p.s. "is harmful" in the subject was chosen to be inflammatory, if 
>> >you are reading this, I've been successful.
>> >Thank you for your time.
>> >
>> >
>> >This message is for the designated recipient only and may contain 
>> >privileged, proprietary, or otherwise private information.
>> >immediately and delete the original.  Any unauthorized use of this 
>> >email is prohibited.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 15 Mar 2009 18:35:19 -0500

a) no need to move them, the ruleset-reference is actually pretty good.  Reading lo-sec, I'm thinking that the function this provides (authorizing a rule maker) is useful.  However, this assumes that the use case is valid...not something I've really thought about all that much - how often does one pass information to someone then give them instructions on how they share that - usually, it's enough to indicate that the information is secret rather than trusting someone else to manage dissemination.

b) There's no need to move policy around with it - this is really just a rehash of the discussion on whether we need to indicate that the location URI follows possession model or not.

> Sent: Saturday, 14 March 2009 5:23 AM

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 Mar 2009 21:48:48 -0400

In the Web context, I actually think there's a lot of value in being  
able to give someone location information with instructions on how it  
may be shared. The example in section 2.1 in lo-sec gets at this a  
bit, as do your run-of-the-mill social network privacy settings  
(allowing, for example, sharing with "everyone," "friends of friends,"  
"friends," or "no one" for a particular piece of data). If this isn't  
such a standard concept yet, I think part of the motivation behind the  
Geopriv privacy rules was the thought that it *should* be.

As to the semantic of retransmission-allowed, I think my understanding  
is closer to James' than Martin's, namely:

If I set retransmission-allowed = false, then there are two options:

(1) the information is not to be shared

(2) there is an authorization policy that governs redistribution of  
this information

If I set retransmission-allowed = true, then the information is  
totally public and can be shared with the world.

I think this makes more sense since the permissions granted by the  
authorization policy are supposed to be additive. Plus, the danger of  
not conveying retransmission-allowed is that you wind up in the same  
situation we have now for most sensitive data: the recipient receives  
it, it has no policy information attached whatsoever, and the  
recipient does what it likes with the data. Even if all of us knew  
that the absence of a policy meant that retransmission was prohibited,  
we would likely be the minority.

Alissa

On Mar 15, 2009, at 7:35 PM, Thomson, Martin wrote:

> a) no need to move them, the ruleset-reference is actually pretty  
> good.  Reading lo-sec, I'm thinking that the function this provides  
> (authorizing a rule maker) is useful.  However, this assumes that  
> the use case is valid...not something I've really thought about all  
> that much - how often does one pass information to someone then give  
> them instructions on how they share that - usually, it's enough to  
> indicate that the information is secret rather than trusting someone  
> else to manage dissemination.
>
> b) There's no need to move policy around with it - this is really  
> just a rehash of the discussion on whether we need to indicate that  
> the location URI follows possession model or not.
>
>> together with location information. I suspect that folks say it  
>> more as
>> a
>> several times already but, as far as I remember, never made a  
>> decision.
>> It
>> the entity that looks at it would have a clue what the URI actually  
>> is.
>> This
>> would then go into the