Hi Eric, I've snipped the thread to just include the issues (3 total) that I'm uncertain as to whether they've been adequately addressed in the -08: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del ivery-08.txt Thanks, Mary. -----Original Message----- From: Eric Rescorla [mailto:ekr@xxxxxxxxxxxxxxxxxxxx] Sent: Friday, June 20, 2008 3:00 PM To: Barnes, Mary (RICH2:AR00) Cc: Eric Rescorla; secdir@xxxxxxx; draft-ietf-geopriv-http-location-delivery@xxxxxxxxxxxxxx; ietf@xxxxxxxx; iesg@xxxxxxxx; geopriv@xxxxxxxx Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07 At Thu, 29 May 2008 07:51:02 -0500, Mary Barnes wrote: > > Hi Eric, > > Thanks for you review and comments. My responses are embedded below > [MB]. > > Mary. > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@xxxxxxxxxxxxxxxxxxxx] > Sent: Saturday, May 24, 2008 9:01 PM > To: secdir@xxxxxxx; > draft-ietf-geopriv-http-location-delivery@xxxxxxxxxxxxxx > Cc: ietf@xxxxxxxx; iesg@xxxxxxxx > Subject: Review of draft-ietf-geopriv-http-location-delivery-07 > > $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 > 2008/05/24 15:03:19 ekr Exp $ > > TECHNICAL > > ---snipped------ > S 6.5.1. > > A "locationURI" SHOULD NOT contain any information that could be used > to identify the Device or Target. Thus, it is RECOMMENDED that the > "locationURI" element contain a public address for the LIS and an > anonymous identifier, such as a local identifier or unlinked > pseudonym. > > 1. This seems like it should be clearer about what is desired. > In particular it's not just "identify" but also "link". > Also this needs to be clarified to indicate the implications > of idetntifiction by position. > > 2. Shouldn't this be MUST strength? > > [MB] This isn't a MUST strength because we had WG discussion/consensus > that we can't mandate LIS behavior. We can make recommendations, but a > LIS may not necessarily follow them. I'm not entirely clear on your > first point as far as "identification by position". [/MB] I mean that knowing where someone is with high enough resolution gives a lot of information about their identity. For instance, if you know that someone is at the AP associated with my house, it seems pretty likely it's me. [MB] But, the identifier doesn't necessarily indicate who the "someone" is. My contrarian example would be my kids are using my home network and I'm in Dublin. How would you know who specifically this location might be associated with? I agree it certainly could. There was a comment on the list yesterday related to this: http://www.ietf.org/mail-archive/web/geopriv/current/msg05895.html So, would changing the text to align with Martin's response be adequate, something like the following: OLD: Thus, it is RECOMMENDED that the "locationURI" element contain a public address for the LIS and an anonymous identifier, such as a local identifier or unlinked pseudonym. NEW: Thus, it is RECOMMENDED that the "locationURI" element contain an address that provides indirect access to the LIS to avoid inadvertently revealing a location that could be associated with a Device. Also, an anonymous identifier is RECOMMENDED, such as a local identifier or unlinked pseudonym. [/MB] --snipped-- > Is this MUST implement or MUST use? Don't the next two sentences > imply MUST use? > > [MB] Per the thread above, that text does need some clarification for > consistency. It should be > MUST "implement" and not MUST "use", so I would propose the > following change: > OLD: > The implementation of HTTP as a transport mechanism MUST implement > TLS as described in [RFC2818]. TLS provides message integrity and > privacy between Device and LIS. The LIS MUST use the server > authentication method described in [RFC2818]; the Device MUST fail a > request if server authentication fails, except in the event of an > emergency. > NEW: > The implementation of HTTP as a transport mechanism MUST implement > TLS as described in [RFC2818]. TLS provides message integrity and > privacy between Device and LIS. privacy->confidentiality. Also, only if the right cipher suiotes are used. [MB] It wasn't clear to me what you were suggested we add in terms of cipher suites. Do you just want that general statement or were you thinking of specific cipher suites that would be appropriate for this application? [/MB] ---snipped---- > S 10.3. > o The network SHOULD have mechanisms that protect against IP address > spoofing, such as those defined in [RFC3704]. > > Is this WG really in a position to levy a SHOULD level requirement > for network ingress filtering? Recall that this is really a global level > technology. Or do you mean something else? > > [MB] Per Richard's response on this thread, the IP address spoofing > recommendation is due to HELD using the devices IP address as the > identifier for the device. In this case it is important to have a > recommendation for IP address spoofing. I think the paragraph prior to > those bullets appropriately qualifies the context of that > recommendation. > [/MB] I can't say I really agree with this assertion about the qualification. This still looks to me like a general levy on the access network. [MB] I'm not certain of the concern here. Doesn't the "SHOULD" account for networks that have other mechanisms, thus this isn't an across the board levy. Or is your concern that we don't have the should not situations identified? [/MB] -Ekr _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf