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 06:57 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 E7F861A883F for <paws@ietfa.amsl.com>; Tue, 23 Sep 2014 23:57:11 -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 FkdSEmsiBtp8 for <paws@ietfa.amsl.com>; Tue, 23 Sep 2014 23:57:09 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9729F1A70FD for <paws@ietf.org>; Tue, 23 Sep 2014 23:57:09 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id id10so5262433vcb.28 for <paws@ietf.org>; Tue, 23 Sep 2014 23:57:08 -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=TPU7srw64+KTEIkI8WeGxjuqo7XmiufjvkUXKthBC0U=; b=O0jJNXl0FSt5Hc5Y9kPGT88jeWl53iHE6YyokIAKQi7N0zDvOWI1uMIJ6FtkSIqxyn HVhf1q6V4lezUF8dhPvUgSzD2zcrfqogpIwi7HjW0fPD9cc0o+MwtzSroBKx/BkhsXc2 iJEI1+g1/iTZh0pB9gNqQlDikARa9zTXLECkFYNXpBV3S6L1sAvuh3UmHuYQRM0DnNC9 qFVm3AgC9cauhQnZMOz5hoxaHSYLEjxQ2Oq4W+v3OEfl2b00jZQ7tqBJK1iLdpzI39nc 6lQN13wiFcc0GRYPRVm5h0PjvXYgbzBf1kN45fqCLZh4cosIBW5pyB1k6Ult2/A7wSMz ANfw==
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=TPU7srw64+KTEIkI8WeGxjuqo7XmiufjvkUXKthBC0U=; b=bXqgrHvmqTTrB05Yif8S1fppSBTDn5WTn2F08Gztyf24kiub7DQUTlpL3/3kGu6XsO SIxliYZFQb8m075/J501+0BvsFK0kpxgFqZSHF6Z1Wd2ONarKxQDhPAiOK03n+G4mK+R 7RVH5nTkQE5XczoqB2EHWtIM8PgF/c8jWYZQM3qkFu0MnFFRwJIujnZG001GBaYnL8uh wZJVB8gRSrITJTqZua4P/3HXf05dAOh53EMLjnJmcMVHaWI2cre0egRcysoVIUgvvj6K mGZjqX7ZjfeD9xeWV4P+MUTM0Nlb3WyoQBmIBJ9bfMqAsNASYpEVeoQNKSCmYF+o7bJK HRTQ==
X-Gm-Message-State: ALoCoQnPlqs0CyLEIyzNpqOD4U6LMbe/7nq40xU7ABjmEEKpjXOO2AU+pNKlpCC77fdJB+5EqAzq
MIME-Version: 1.0
X-Received: by 10.52.175.5 with SMTP id bw5mr3518854vdc.66.1411541828667; Tue, 23 Sep 2014 23:57:08 -0700 (PDT)
Received: by 10.52.236.232 with HTTP; Tue, 23 Sep 2014 23:57:08 -0700 (PDT)
In-Reply-To: <D0471F58.5A0A7%alissa@cooperw.in>
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>
Date: Tue, 23 Sep 2014 23:57:08 -0700
Message-ID: <CABEV9RONQjut1_AYF-TDBhs_YuVBG4912GVqbaDpbEgSp50A9w@mail.gmail.com>
From: Vincent Chen <vchen@google.com>
To: Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary=20cf3071cebc48c3a10503ca31d1
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/JWg6f-db6A9t52W9uSANWaD3D7o
Cc: "paws@ietf.org" <paws@ietf.org>, "paws-chairs@tools.ietf.org" <paws-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, 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 06:57:12 -0000

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