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. _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
