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

Vincent Chen <vchen@google.com> Wed, 24 September 2014 22:36 UTC

Return-Path: <vchen@google.com>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EE1A1ADA for <paws@ietfa.amsl.com>; Wed, 24 Sep 2014 15:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level:
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJJGnQvYp54c for <paws@ietfa.amsl.com>; Wed, 24 Sep 2014 15:36:05 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7831C1A1ADE for <paws@ietf.org>; Wed, 24 Sep 2014 15:35:57 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id le20so7275852vcb.4 for <paws@ietf.org>; Wed, 24 Sep 2014 15:35:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V1GfIR+R6M16QmH+5Y2LKAF8qFjbRDLNwZqd0sN9H0Y=; b=EBzovHNfTgBgOLucCV43vhmobP4zrWiU+bjyeNcYj6AEecXiDCu7kiv0/fS9LM88Db ++TQjr/TzflLCHllKtFNxxhtbqhO599wpkTogOiqxcIrQCdRGWF4I/0BOOvWxlUrmLbC bOEoi8nIoDyF/rKwEKFf0LW7gWzJ2C7itsrw9iCUxGO317vAY7tdyjWQw0ejHcQHH6q4 kgfhGCo0wc0vKu25o2auzzSTcWXvXKikhwel9Zx8Npq/X3XDlU8hyxkFJ9InxstHxupW TVrgbVpSdJtz/edVqOZaxS+w1Z9ydHiKu3u2rqHIjAARdbVuITOTWO+XpkFxX+4Hz0rB TJ4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V1GfIR+R6M16QmH+5Y2LKAF8qFjbRDLNwZqd0sN9H0Y=; b=U/Yd3t8VpgLAeayty+BCgowv+MTxe3OuOHrG4g/BFZJ69hQm957AKY1dKxGXNG+3Mp QeiMsTn1b1Mgesx/QWhjZWKEqPFid/paUnc2SemtDMLoYkRcR8o5Hk5p/OlFwz3NK7c/ As5yCZhGA/b9KMQ2313QByDdQPf7RXHZ00bTKTsSFC6FEv5j+qTXxiIJjmW3R+BIa9rM It3gCRxYNvPwoXEpIy5D3pVqg0FK/l8P0ge+q2kf/x2HIF3c6BPs7Mg7+2o819RmV7wp LphbnLsweWTjnwXDlq4tkZZfd5DaQmNpTJHUWANuADbv9S6B0SWkq4ujBKZz/oS+p7rn YcGg==
X-Gm-Message-State: ALoCoQlBN0CZ6BoHbOTVdsiVGwrHZA+RzNWqLXJCcB42M1fUvpA0iOhwJwcl7Rml5CV5dCJ0rZgH
MIME-Version: 1.0
X-Received: by 10.52.190.130 with SMTP id gq2mr7027378vdc.16.1411598156448; Wed, 24 Sep 2014 15:35:56 -0700 (PDT)
Received: by 10.52.130.205 with HTTP; Wed, 24 Sep 2014 15:35:56 -0700 (PDT)
In-Reply-To: <5423322D.2080902@qti.qualcomm.com>
References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> <CABEV9ROW=KhQDCU5=X+SrtPAAOwd0QgvKJh_-owQ4b1CvdNvog@mail.gmail.com> <D0388B73.57841%alissa@cooperw.in> <CABEV9ROcLstZ1gpFrYpeAo07o+pp6QPeF4ovm_GXDB8DdWCiGw@mail.gmail.com> <D0471F58.5A0A7%alissa@cooperw.in> <CABEV9RONQjut1_AYF-TDBhs_YuVBG4912GVqbaDpbEgSp50A9w@mail.gmail.com> <FB5F7B5B-04FD-4F15-8DD8-1E038839869F@brianrosen.net> <D0487602.5A611%alissa@cooperw.in> <5423322D.2080902@qti.qualcomm.com>
Date: Wed, 24 Sep 2014 15:35:56 -0700
Message-ID: <CABEV9RMQxf2XT8rT7QUxayot+4Av8EKHgZcMvkVBbeiZG5t_1g@mail.gmail.com>
From: Vincent Chen <vchen@google.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary=089e0122ee42ae61560503d74e04
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/QuwtH3TjUjUC2ZnlCUIa07Orw_I
Cc: "paws-chairs@tools.ietf.org" <paws-chairs@tools.ietf.org>, "paws@ietf.org" <paws@ietf.org>, The IESG <iesg@ietf.org>, Brian Rosen <br@brianrosen.net>, draft-ietf-paws-protocol@tools.ietf.org
Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Sep 2014 22:36:09 -0000

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 <presnick@qti.qualcomm.com>;
wrote:

>  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" <br@brianrosen.net>; 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 <vchen@google.com>; wrote:
>
>  Hi Alissa,
>
> On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <alissa@cooperw.in>; 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/> <http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>


-- 
-vince