Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)
Alissa Cooper <alissa@cooperw.in> Tue, 23 September 2014 20:01 UTC
Return-Path: <alissa@cooperw.in>
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 BC1AC1A88B8 for <paws@ietfa.amsl.com>; Tue, 23 Sep 2014 13:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=ham
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 OEAsvMNfDeMV for <paws@ietfa.amsl.com>; Tue, 23 Sep 2014 13:01:30 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4191A1BE0 for <paws@ietf.org>; Tue, 23 Sep 2014 13:01:23 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 7E9322126E for <paws@ietf.org>; Tue, 23 Sep 2014 16:01:22 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 23 Sep 2014 16:01:22 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=y7Tk5PFiFXo9lfRhqO86wOU D/PM=; b=F4U9TwEllTYCrVxwo0HeVW54yzxnZ5AiZSainaFaNEmuw+6dBsTNIqv FzxBSqsq6RsfJjmbVvoJDOjy6GvsD5eXHV3wnGesnJgOUogBbcDjckBmDoTxiMzZ 9QddOxUZ9P0x/1o0S7DLH4I1U7Xc4XPY6Z52PJhC0BsxzZDngd48=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=y7Tk5PFiFXo9lfRhqO86wOUD/PM=; b=gsiRuBTXl8NbvsIAQ5/eX6HAWSq4 WOJKIimd/HxwKv53HcwbklmkoIGhh7P7Sfca5S2/mrbR9HWZV9XXMaN9+GimSaTh sm15RjbvLQQIdfGyO9Aj2W8PPsr6dIIyPllhUpeOIoeleO1XrwOQQaIEe4q5r2fq OByyZVeO7Yo5s/8=
X-Sasl-enc: xw8n/BGQZfAClmhJUVNDthICsk4dyJK+VW8qfqRbpz9z 1411502481
Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B3B06801E2; Tue, 23 Sep 2014 16:01:17 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.4.3.140616
Date: Tue, 23 Sep 2014 13:01:12 -0700
From: Alissa Cooper <alissa@cooperw.in>
To: Vincent Chen <vchen@google.com>
Message-ID: <D0471F58.5A0A7%alissa@cooperw.in>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)
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>
In-Reply-To: <CABEV9ROcLstZ1gpFrYpeAo07o+pp6QPeF4ovm_GXDB8DdWCiGw@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3494322081_6454662"
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/aP2LC3-2mjwuA3PshELwkJDIRb8
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: Tue, 23 Sep 2014 20:01:34 -0000
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" <vchen@google.com> 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 <alissa@cooperw.in> 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" <vchen@google.com> 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
- [paws] Alissa Cooper's Discuss on draft-ietf-paws… Alissa Cooper
- [paws] Comment on draft-ietf-paws-protocol-14 Russ Housley
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Pete Resnick
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Vincent Chen
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Pete Resnick
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Pete Resnick
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Vincent Chen
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Gabor Bajko
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Vincent Chen
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Vincent Chen
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Pete Resnick
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Vincent Chen
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Pete Resnick
- Re: [paws] Alissa Cooper's Discuss on draft-ietf-… Vincent Chen