[paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS)

"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Wed, 20 August 2014 20:31 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.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 2F4981A0AF0; Wed, 20 Aug 2014 13:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] 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 4tZFiItyl72V; Wed, 20 Aug 2014 13:31:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20431A0B0E; Wed, 20 Aug 2014 13:31:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140820203127.25270.64032.idtracker@ietfa.amsl.com>
Date: Wed, 20 Aug 2014 13:31:27 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/2HxfQN4Ly_o-Hw2Uv07OS0r7s-w
X-Mailman-Approved-At: Thu, 21 Aug 2014 09:34:43 -0700
Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org
Subject: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Aug 2014 20:31:29 -0000

Kathleen Moriarty 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
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for doing this work, the draft looks good and my discuss should be
easy enough to address as I am just looking for some clarifying
information that may be helpful if I didn't miss the answer somewhere
else.

Can clients query any database entries or is the interface restricted to
the list of supported interactions?   I assume the answer is that it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.

Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.   

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example) and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.  I think this should be on a field basis in
terms of sensitive elements where relevant. 

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users,
but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices. 
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).  This may sound crazy, but layered attacks are very real.  

Is there anything that prevents a client from fingerprinting?

Perhaps recommendations at the field level would help implementors
understand these risks (privacy & security) and then they may be more
motivated to enable authenticated and encrypted access.  This wouldn't be
necessary for all fields, just the ones that could be used in attacks or
reveal privacy related information.  Implementers may take the optional
field use more seriously or create options in application interfaces so
that users are then aware of the risks with these fields and make
different choices.  Ideally, there would be a limited set of data
returned based on role information so that devices or other clients only
get what they need as opposed to what is available.  I didn't see any
mention of restrictions on who could access what (role based access), is
that possible?  I'm not sure if the primary & secondary users allow for
this?

Thanks in advance.