Subject: RE: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 14 Nov 2005 20:01:28 -0500

I'm find with this restriction.

- Bernie 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Monday, November 14, 2005 7:52 PM
> To: Bernie Volz (volz)
> Cc: Ralph Droms (rdroms); DHCP discussion list; Ted Hardie; 
> [email-masked]
> Subject: Re: [dhcwg] Re: I-D 
> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> 
> 
> 
> Bernie Volz (volz) wrote:
> > Henning:
> > 
> > I assume this default "do not distribute" policy applies for either
> > direction (client to server (server should not distribute) 
> and server to
> > client (client should not distribute)) or do you propose to 
> have this
> > apply only when the client sends it to the server?
> 
> There is a crucial difference, as John Schnitzlein pointed 
> out: The DHCP 
> server is telling the client where it is, which the client is 
> presumably 
> is free to share with whomever it likes. ("It's *my* location 
> and I'll 
> do what I want with it.") I'm ignoring the case here of the abductee 
> case where the kidnap victim is told that if he reveals his location, 
> he'll be shot. I don't think we need to support this 
> particular kind of 
> enforced location privacy and I doubt that RFC injunctions would be 
> particularly effective in this case.
> 
> If the client tells the server where it is, the client is telling a 
> third party something that has potential privacy implications. Just 
> because I'm telling Verizon where my 802.16 wireless modem is 
> located so 
> that it can help with 911 calls or dispatch a repair truck 
> doesn't mean 
> that I'd like Verizon to sell or give this information to the 
> world at 
> large. In PIDF-LO, there is a basic privacy indicator that 
> allows me to 
> make a choice ("keep this to yourself"); this is not currently in the 
> geo or civic DHCP options. Thus, the suggestion for a 
> privacy-friendly 
> default policy.
> 
> 
> 
> > 
> > If this policy doesn't apply when from server to client 
> (what the I-D
> > currently allows), what policy does apply to the 
> information the client
> > receives as this privacy information isn't communicated? 
> And, thus isn't
> > this be a flaw in the current document that should be addressed
> > (irrespective of the issue I raised below).
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Nov 2005 15:36:27 -0800

Because of a family medical issue, I've been unable to follow the list for the past
week or so.  Sorry to revive the thread, but I want us to be clear about the
proposals on the table.  I've tried to summarize them in a brief way below.

>From Andy:

We treat DHCP server-to-client as a sighting function.  That makes the information
sent  "location information" under GeoPriv terms, which is exempt from the
GeoPriv privacy considerations because of the problems with application of
the rules before it is possible to construct a location object.    We do not
treat DHCP client-to-server as a sighting function (since the location is
the client's, not the servers), and so the location passed is subject to
GeoPriv privacy concerns.  Since DHCP is not carrying PIDF-LO,  it
should not carry anything, and the client-to-server direction should be
ruled out.

>From Bernie:

The client-to-server direction should not be ruled out, but its use should
be restricted by the Security Considerations set out in GeoPriv documents.
He points in particular to RFC 3694 (I believe to the Protocol Attacks in 4.1). 

He believes that this puts the use of the information passed client-to-server
under the administrative policy control of the server:

>For (2), this depends on if and how the server uses the received
>information. And, that is up to the administrative policies on the
>server.

>From Henning:

Let's not make it a MUST NOT, but instead indicate that the default permission
for anything sent from client-to-server is "do not distribute".   Since the client's
sending it indicates permission for the server to have it, this restricts the
communication from going anywhere else.  This is a compromise position
to accomplish the two perceived goals:  it should not be a protocol error,
but the information should be restricted.

I hope this captures, in brief, the basic positions.  If I have gotten any of
these wrong, please correct me.

In general, I support Henning's proposed compromise, but I am concerned that
some supporting it may not recognize the full implications.  Reading RFC 3694,
as Bernie suggests, is important to digging those out.  My reading is that
with a default of "do no distribute" and no other way within the client-to-server
exchange to indicate a non-default set of rules, there is no way that the information
can move beyond the DHC server to any other server  (Server here does not mean
box; it means any other function, even if it is within the same administrative
domain or resident in the same box).  According to RFC 3694's model,
changing that default is not within the policy control of the server--it is
a function of the rule maker (see section 6).  The DHC client would be the
rule maker here.    If I have misunderstood, and we agree that this is the
case, then I believe a short of RFC Editor note can be added (or a quick
respin done).
			regards,
				Ted Hardie