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 17:20:38 -0500

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?

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).

- Bernie

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Monday, November 14, 2005 4:55 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
> 
> Thanks for your comments. I thought this issue had been resolved, but 
> let me try to introduce a compromise position. One of the 
> issues raised 
> in the past is that the location information does not have a privacy 
> section (unlike PIDF-LO). However, this can be resolved by 
> declaring a 
> default "do not distribute" policy for this application.
> 
> [I personally don't have a strong opinion on this subject and 
> just want 
> to get this draft done, after almost three years.]
> 
> Henning
> 
> Bernie Volz (volz) wrote:
> > Having looked over this draft, I object to the language 
> (MUST NOT) that
> > prohibits the client from sending this option (with data) 
> to the server.
> > 
> > While I understand that there are security implications of doing so,
> > pointing out those security issues (such as referencing RFC 3694,
> > "Threat Analysis of the Geopriv Protocol") and encouraging 
> use only on
> > secured networks or under special circumstances makes much 
> more sense
> > than a blanket MUST NOT.
> > 
> > There are two core security threats in allowing this 
> information to be
> > sent from client to server:
> > 1) Leakage of location information to other devices on the network
> > 2) Alternation or faking of location information to the server
> > 
> > For (1), many of the devices could obtain this information in the
> > response from the server. Admittedly it is a bit easier to 
> capture the
> > client's transmission (as it is broadcast in IP4 or 
> multicast in IPv6).
> > But, the difference here is fairly minor in most networks.
> > 
> > There are networks that are secured (perhaps physically) 
> and there are
> > also times when sending this information to a server is extremely
> > desirable and not a security threat, such as during build-out of the
> > cable plant.
> > 
> > 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.
> > 
> > For example, a server might allow a client to communicate one of <n>
> > possible locations at which it may be located or allow a client to
> > augment the information a server has. If and how a server USES this
> > information and what of the received information it sends 
> to the client
> > is up to the administrative policies in the server.
> > 
> > Allowing the client to send in information also may be useful to the
> > server -- it may keep both the client's reported and the server's
> > configured location for the client.
> > 
> > This is no different in what the client may do when 
> receiving data from
> > the server -- it can ignore this information, use all, or 
> use portions
> > of it.
> > 
> > 
> > There's also
> > 
> http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhc-geo
> -lci-upstr
> > eam-00.txt which is attempting to update RFC 3825 to allow 
> use of that
> > DHCP option in either direction (server to client and 
> client to server).
> > 
> > Changing the language in this draft now avoids the need for 
> further work
> > on this subject. And, it isn't like you need to write an extensive
> > security considerations sections -- you have RFC 3694 to 
> reference as
> > the GEOPRIV WG has already done that work.
> > 
> > - Bernie Volz
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] 
> >>On Behalf Of Ralph Droms (rdroms)
> >>Sent: Thursday, November 10, 2005 2:16 PM
> >>To: DHCP discussion list
> >>Subject: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> >>
> >>dhc WG members: Please review and comment on 
> draft-ietf-geopriv-dhcp-
> >>civil-07.txt.
> >>
> >>Back in September, I sent a message to the dhcwg mailing list 
> >>asking for
> >>WG review of draft-ietf-geopriv-dhcp-civil-07.txt (original 
> e-mail is
> >>appended to this message).  Shortly after I sent that message, Ted
> >>Hardie sent e-mail to the effect that there was another outstanding
> >>Discuss on draft-ietf-geopriv-dhcp-civil: 
> >>
> >>On Mon, 2005-09-19 at 10:16 -0700, Ted Hardie wrote:
> >>
> >>>Thanks to Ralph for forwarding this to the group.  There 
> >>
> >>may be a further revision,
> >>
> >>>however, as David Kessens still has an outstanding discuss 
> >>
> >>which is not yet
> >>
> >>>resolved.  David has agreed to update the discuss text to 
> >>
> >>indicate more clearly
> >>
> >>>the points of discussion but has not yet done so.  Until 
> >>
> >>that is complete, it is
> >>
> >>>not clear whether further changes to this aspect of the 
> >>
> >>document will be requested.
> >>
> >>>Your review of this draft is, of course, appreciated, but 
> >>
> >>please be aware that there may
> >>
> >>>be a second request.
> >>
> >>Just to be clear, it is not definitely the case that a -08 
> >>revision will
> >>be published.  dhc WG members should review the -07 
> revision and reply
> >>with comments to the [email-masked] mailing list by Friday, 
> >>2005-11-18.
> >>
> >>- Ralph
> >>
> >>=====
> >>
> >>Following up on the announcement of the publication of draft-ietf-
> >>geopriv-dhcp-civil-07.txt, which John Schnizlein forwarded to the
> >>mailing list, the -04 revision of this draft was reviewed by 
> >>the dhc WG
> >>several months ago, in a joint last call with the geopriv WG. 
> >> The draft
> >>was then submitted to the IESG.  
> draft-ietf-geopriv-dhcp-civil-07.txt
> >>includes changes in response to comments received during the IESG
> >>review.  Because this specification involves DHCP, the dhc WG has an
> >>opportunity for a final review of the draft.  Accordingly, 
> if you have
> >>any comments about the draft, please respond by 1700EDT on 
> >>Thu, 9/22.  I
> >>will forward any responses to the IESG and the geopriv WG chairs.
> >>
> >>I prepared a diff of the -04 and -07 versions, but haven't 
> >>sent it with
> >>this announcement because it's about 200KB (using 
> side-by-side rfcdiff
> >>tool).  Let me know if you'd like me to send you an individual copy.
> >>
> >>- Ralph
> >>
> >>
> >>_______________________________________________
> >>dhcwg mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/dhcwg
> >>
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 19:51:46 -0500

> 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.