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

Alissa Cooper <> Fri, 12 September 2014 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 679CD1A03FE for <>; Fri, 12 Sep 2014 09:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n3olt0m2HK6s for <>; Fri, 12 Sep 2014 09:03:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A4B11A02BE for <>; Fri, 12 Sep 2014 09:03:52 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal []) by gateway2.nyi.internal (Postfix) with ESMTP id 92D212054D for <>; Fri, 12 Sep 2014 12:03:51 -0400 (EDT)
Received: from frontend1 ([]) by compute5.internal (MEProxy); Fri, 12 Sep 2014 12:03:51 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=XCGBenqrxYg4B4ezeajN6AY 9cWM=; b=F55e0WcXRguxvATtu1pesiHa9nTW7mGCDhBEkFKCK0Rn2E1Tl5MAdg5 Uw09O6b2A9RVPopruNikWE8fB/h+fhYTBSglh9ml3xMnxRWOR7AoMBOcSs++2VBm NL1MV8BONUdPjFtFW7SFqZWk1DnDcOx5e5qr/8EuZG1cvWDoDjEY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=XCGBenqrxYg4B4ezeajN6AY9cWM=; b=ZwbDObfYqsuyzSjrek0bT32EdCG5 G7ViIf/XXZ94kKf+RZG8hL83cejGEddXcgSBO3x5IKXiYmvJbtvlQkoh6hDCUjBh gwOhuCga9oNnZ7gu2ljccTKWiE7Cfn9kNkoIWg0BD9lFT10zYDwTXUTPUpDR2hRl NMzrzEIsaYiHzpI=
X-Sasl-enc: DqgWc7HnQHW7Xo3kk0jgUhBQTwLA6buQNH1YoHz0k08g 1410537830
Received: from [] (unknown []) by (Postfix) with ESMTPA id D0456C008FC; Fri, 12 Sep 2014 12:03:48 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/
Date: Fri, 12 Sep 2014 12:03:44 -0400
From: Alissa Cooper <>
To: Vincent Chen <>
Message-ID: <>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)
References: <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3493368231_34316078"
Cc: "" <>, "" <>, The IESG <>,
Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Sep 2014 16:03:56 -0000

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


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