Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

[Pete Resnick <[e-mail]>]

It sounds like we're closing in. Just in case, I've put the document on 
tomorrow's informal IESG telechat and invited Vince to join us (neither 
of the chairs can make it). If it resolves before then, great. If not, 
we'll work it out in real time.

Thanks for working on this, all.

pr

On 9/24/14 3:28 PM, Alissa Cooper wrote:
> On 9/24/14, 6:17 AM, "Brian Rosen" <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On the location issue, this is well traveled ground.
>
>     In many cases, the location of the device is no where near a
>     boundary, and thus can be relatively imprecise.  As you get closer
>     to a boundary, you need more precision in order to know if which
>     side of the boundary you are on.  In white space, sometimes the
>     regulator specifies the required accuracy of location, sometimes
>     it doesn't.
>
>     If you think about a canonical wireless microphone, you want
>     location down to maybe 100 meters to avoid having problems with
>     the microphone, but allow use of the spectrum where there is no
>     problem of interference.  I wouldn't want us to specify some
>     default accuracy, but it really does need to be fairly accurate
>     given current technology.  We're starting to see location
>     determination systems that could give us less than 2 meter
>     accuracy in some environments, and that's probably beyond what we
>     need.
>
>     So you both are right.  Where the regulator specifies accuracy,
>     that's it, you send that, you need not send more.
>     When the regulator doesn't specify, someone has to put out a spec,
>     and the clients need not send more accurate location.
>
>
> Maybe we can build off of this and the text that Vince added in the 
> --18 to make one additional recommendation, at the end of the new 
> paragraph in Section 10:
>
> "Similarly, regulators should require, and implementations should 
> provide, device location at a level of granularity only as precise as 
> necessary to support accurate database responses."
>
> Or something like that.
>
> Re-reading the new text, I agree that the fingerprinting bit is covered.
>
> Alissa
>
>
>     But, we've also looked at obfuscation when you want to report
>     location less precise than what you have.  What we know is that
>     it's really, really hard to do it.
>
>     Brian
>
>     On Sep 24, 2014, at 2:57 AM, Vincent Chen <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>>     Hi Alissa,
>>
>>     On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hi Vince,
>>
>>         Thanks. I like the text you added, but I think the bit about
>>         fingerprinting and the caution to implementations about not
>>         over-sharing that I had suggested are both important --- any
>>         reason not to include them explicitly?
>>
>>
>>     Sorry I did not respond directly to these points. Here's my train
>>     of thought.
>>
>>     1. The whole point of the White Space Database is to give
>>     information about available spectrum at a location. The location
>>     has to be precise enough for the information to be valid. So it
>>     seems odd for PAWS to recommend that a device give imprecise
>>     location.
>>
>>     2. While PAWS does indicate that serial number is optional, it is
>>     unlikely that a regulator will make it optional.
>>
>>     In any cases I felt the statements indicating risk of tracking
>>     covers tracking via explicit information provided by the device
>>     and via implicit information derived from fingerprinting.
>>
>>     -vince
>>
>>
>>
>>                 Now that the document is clear that Slave device
>>                 location and serial number are optional (unless
>>                 required by a ruleset), I think the remaining task on
>>                 the above three points is to add a bit of text to
>>                 Section 10 to explain the potential privacy threats
>>                 from authorized databases, perhaps as a short
>>                 paragraph or two at the end of Section 10. Something
>>                 along these lines (just a suggestion, feel free to
>>                 reject this entirely or use bits that you like):
>>
>>                 "In addition to the privacy risks described above, in
>>                 some cases, users of Master or Slave devices may open
>>                 themselves up to privacy risks related to the
>>                 secondary use of PAWS-related information by a
>>                 database administrator. For example, in situations
>>                 where rulesets require that Master or Slave devices
>>                 uniquely identify themselves (via the
>>                 DeviceDescriptor or DeviceOwner parameters), database
>>                 administrators may be able to use that information to
>>                 track connectivity activity over time, or they may
>>                 share such tracking information with third parties.
>>                 Where Master or Slave devices choose to provide or
>>                 are required to provide geolocation information in
>>                 conjunction with unique device identifiers, this
>>                 capability may further extent to location tracking.
>>                 Even where a device does not provide a specific
>>                 unique identifier, a database administrator may be
>>                 able to uniquely fingerprint a device based on the
>>                 combination of other information provided in
>>                 DeviceDescriptor or DeviceCapabilities parameters.
>>
>>                 In cases where devices have a choice to not send
>>                 device-identifying information or geolocation, or to
>>                 send less granular geolocation (i.e., a region rather
>>                 than a point), PAWS implementations can reduce the
>>                 risks associated with secondary use by not sending
>>                 that information. Where rulesets require this
>>                 information to be sent, these risks require
>>                 out-of-band mitigation (e.g., public statements or
>>                 contractual terms preventing secondary use)."
>>
>>                 Thanks,
>>                 Alissa
>>
>>
>>
>>                         ----------------------------------------------------------------------
>>                         COMMENT:
>>                         ----------------------------------------------------------------------
>>
>>                         = Shepherd write-up=
>>                         "An in-depth review by a JSON expert might be
>>                         useful."
>>
>>                         Did that happen?
>>
>>
>>                     Tim Bray had looked at it before final call.
>>
>>
>>                         = Section 1 =
>>                         "It opens the door for innovations in spectrum
>>                            management that can incorporate a variety
>>                         of parameters, including
>>                            user location and time.  In the future, it
>>                         also can include other
>>                            parameters, such as user priority, time,
>>                         signal type and power,
>>                            spectrum supply and demand, payment or
>>                         micro-auction bidding, and
>>                            more."
>>
>>                         Time seems to be listed both as a current
>>                         parameter and a future one,
>>                         which is confusing.
>>
>>
>>                     Agreed. The second "time" should be removed.
>>
>>
>>                         = Section 4.4 =
>>                         "FCC rules, for example, require that a
>>                         'Fixed Device'
>>                            register its owner and operator contact
>>                         information, its device
>>                            identifier, its location, and its antenna
>>                         height."
>>
>>                         It would be nice to have a citation for the
>>                         rules referenced here.
>>
>>
>>                     OK.
>>
>>
>>                         = Section 5.1 =
>>                         Feel free to ignore this if it's completely
>>                         misguided, but does altitude
>>                         really not matter? Are we sure this protocol
>>                         won't be re-used for devices
>>                         on airplanes trying to find available
>>                         spectrum? (I note that in RFC 6953,
>>                         requirement D.1 specifies that the data model
>>                         must support "the height
>>                         and its uncertainty" -- I have no idea what
>>                         "the height" means or if it
>>                         is related to altitude.)
>>
>>
>>                     See Section 5.3 on "height" of the antenna. It's
>>                     separated out, from the "latitude, longitude"
>>                     specification
>>                     of GeoLocation. It allows specification with
>>                     respect to ground level or mean sea level, and is
>>                     intended
>>                     for Fixed devices, rather than mobile devices.
>>
>>                     From the current regulator's perspective, the
>>                     allowed power for mobile devices is low enough that
>>                     height does not matter.
>>
>>
>>                         = Section 10 =
>>                         I agree with Stephen that the database
>>                         operator should be considered as a
>>                         potential adversary from the standpoint of
>>                         potentially being able to
>>                         create a fine-grained database that tracks
>>                         the locations and spectrum use
>>                         patterns of individual devices. That data
>>                         could certainly be abused.
>>
>>
>>                     So just listing that as a potential threat and
>>                     declare that fixing this as out of scope is
>>                     sufficient?
>>
>>                     Or do we need to state that Databases MUST not
>>                     track? I can see how anonymized tracking
>>                     can be useful for spectrum management in the
>>                     future, much like anonymized tracking of car
>>                     locations
>>                     provide valuable traffic information for
>>                     navigation systems.
>>
>>                     -- 
>>                     -vince
>>
>>
>>
>>
>>             -- 
>>             -vince
>>
>>
>>
>>
>>     -- 
>>     -vince
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]