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

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Sep 2014 12:03:44 -0400

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" <[email-masked]> 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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Sep 2014 12:04:56 -0400

On 8/21/14, 4:32 PM, "Gabor Bajko" <[email-masked]> wrote:

> 
> 
> 
> On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper <[email-masked]> wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-paws-protocol-14: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> 
>> DISCUSS:
>> I'm glad this work is being done in the IETF, thanks for all your
>> effort.
>> 
>> A couple of my points below have overlaps with some of Stephen's points.
>> 
>> = Shepherd write-up =
>> "Yes, there were 2 IPR disclosures filed that reference this document.
>> They were discussed in the WG, and nobody came forward to say that they'd
>> like to change anything in the document because of the disclosures."
>> 
>> But there are 3 IPR disclosures in the tracker, not 2. Were all three
>> discussed in the WG?
>> 
> This  3rd IPR disclosure seems to have surfaced 2 months after the shepherd
> write-up, that is why it is not mentioned in the write-up.
> I think the best we can do now is to consult the WG about this disclosure in
> parallel with the iesg evaluations.

I saw Pete’s note to the mailing list about the third IPR disclosure but
haven’t seen any responses (right?). What is the status?

Thanks,
Alissa

> Gabor

---

From: Vincent Chen <[email-masked]>
Date: Mon, 22 Sep 2014 00:16:56 -0700

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 <[email-masked]> wrote:

> The regulator want to have the ability to black list ranges of serial
> numbers, if it
> 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):
>
> information to track connectivity activity over time, or they may share
> such tracking information with third parties. Where Master or Slave devices
> 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.
>
> of GeoLocation. It allows specification with respect to ground level or
> mean sea level, and is intended
> From the current regulator's perspective, the allowed power for mobile
> devices is low enough that
> height does not matter.
>
>
>
>>
>> = Section 10 =
> 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

-- 
-vince

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 23 Sep 2014 13:01:12 -0700

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" <[email-masked]> wrote:

> suggestions. I've simplified the text a bit, but, hopefully, it addresses your
> concerns. Please let me know what you think.
> 
>> 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.
>> 
>> 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
>> 
>>>  
>>>> 
>>>>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 23 Sep 2014 15:07:27 -0500

On 8/20/14 11:52 AM, Alissa Cooper wrote:

> ...there are 3 IPR disclosures in the tracker, not 2. Were all three
> discussed in the WG?
>    

The third IPR disclosure was pointed out to the WG. There was a short 
discussion, and nobody expressed concerns about this disclosure 
impacting the work. So I believe this portion of your DISCUSS is addressed.

It sounds like you and Vince are winding up the rest of your DISCUSSion. 
Once you are satisfied, I'll give the document a once-over to make sure 
that all of the other comments were addressed.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Vincent Chen <[email-masked]>
Date: Tue, 23 Sep 2014 23:57:08 -0700

Hi Alissa,

On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[email-masked]> 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

>> "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.
>>
>> So just listing that as a potential threat and declare that fixing this
>> as out of scope is sufficient?
>>

-- 
-vince

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 24 Sep 2014 13:28:13 -0700

On 9/24/14, 6:17 AM, "Brian Rosen" <[email-masked]> 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 <[email-masked]> wrote:
> 
>> Hi Alissa,
>> 
>> Sorry I did not respond directly to these points. Here's my train of thought.
>> 
>>>>> 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):
>>>>> 
>>>>> such tracking information with third parties. Where Master or Slave
>>>>> devices choose to provide or are required to provide geolocation

---

From: Pete Resnick <[email-masked]>
Date: Wed, 24 Sep 2014 16:05:49 -0500

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" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     Hi Alissa,
>>
>>     On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hi Vince,
>>
>>         fingerprinting and the caution to implementations about not
>>         over-sharing that I had suggested are both important --- any
>>         reason not to include them explicitly?
>>
>>
>>     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
>>                 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
>>
>>
>>
>>                     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
>>                     From the current regulator's perspective, the
>>                     allowed power for mobile devices is low enough that
>>                     height does not matter.
>>
>>
>>                         = Section 10 =
>>                     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

---

From: Vincent Chen <[email-masked]>
Date: Wed, 24 Sep 2014 15:35:56 -0700

Thanks, Alissa!

The new sentence looks good and strikes a great balance. I'll add and
upload a new version.

-vince

On Wed, Sep 24, 2014 at 2:05 PM, Pete Resnick <[email-masked]>
wrote:

> 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.
>
>  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.
>  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
> necessary to support accurate database responses.”
>
>  Or something like that.
>
>  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
>
>  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.
>
>>>  "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
>>>  See Section 5.3 on "height" of the antenna. It's separated out, from
>>> the "latitude, longitude" specification
>>>  So just listing that as a potential threat and declare that fixing
>>> this as out of scope is sufficient?
>>>
>>> can be useful for spectrum management in the future, much like
>>> anonymized tracking of car locations
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

-- 
-vince