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

[Alissa Cooper <[e-mail]>]

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?

Alissa

On 9/22/14, 12:16 AM, "Vincent Chen" <[e-mail]> wrote:

> Hi Alissa,
> 
> Sorry for the delayed response. I've uploaded draft 18, incorporating your
> suggestions. I've simplified the text a bit, but, hopefully, it addresses your
> concerns. Please let me know what you think.
> 
> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-18
> 
> Thanks.
> 
> -vince
> 
> On Fri, Sep 12, 2014 at 9:03 AM, Alissa Cooper <[e-mail]> wrote:
>> Hi Vincent,
>> 
>> I’ve taken a look at the –17. Thanks for accommodating many of my DISCUSS
>> points. I have a one response below on a couple of remaining issues.
>> 
>> On 8/21/14, 12:59 AM, "Vincent Chen" <[e-mail]> wrote:
>> 
>>> 
>>>> 
>>>> = Section 5.1 =
>>>> I'd like to discuss why the single point location format needs to be
>>>> supported here. Is it really the case that a portion of whitespace
>>>> spectrum will ever be available only at a single point, as opposed to a
>>>> region? If not, it seems like sending a point (and, moreover, allowing
>>>> region to be unsupported but not point) divulges more precise information
>>>> about the requesting device than is ever actually necessary to fulfill
>>>> the goals of this protocol. Do regulators require a single point? Why?
>>> 
>>> The resulting spectrum is valid for 100m (typically) radius around that
>>> point.
>>> 
>>> Computation of available spectrum for a region is actually complex and not
>>> well defined...
>>>  
>>>> 
>>>> = Section 5.2 =
>>>> I'd like to discuss why the device serial number needs to be included in
>>>> the device descriptor, rather than some (perhaps persistent) randomly
>>>> generated device identifier that is used only in the context of this
>>>> protocol (which would better protect the privacy of the user of the
>>>> device, since the whitespaces database administrator wouldn't be able to
>>>> correlate the device's spectrum requests with other activities linked to
>>>> the serial number). It's not really clear why serial number is collected
>>>> since both this document and RFC 6953 note the protocol does not defend
>>>> against abuse or mis-use of spectrum.
>>> 
>>> The regulator want to have the ability to black list ranges of serial
>>> numbers, if it
>>> determines that a series was defective. The Databases must use the serial
>>> number
>>> to determine it can return available spectrum.
>>>  
>>>> 
>>>> I'm asking the above two questions in light of requirement P.7 from RFC
>>>> 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of
>>>> device-provided data where such protection is feasible, allowed, and
>>>> desired."
>>>> 
>>>> A separate interesting question that does not seem to be addressed
>>>> anywhere in the draft is whether a device can be fingerprinted by the
>>>> database operator by virtue of the collection of elements it sends
>>>> (rulesetIds, manufacturer, model, antenna characteristics, device
>>>> capabilities, etc.) even if it doesn't send a serial number or device
>>>> owner information that uniquely identify it. That seems worth discussion
>>>> in Section 10.
>>> 
>>> What should the discussion say? Just that it is possible? or does it need
>>> to have a solution?
>> 
>> 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