[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                              S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Informational                         November 13, 2017
Expires: May 17, 2018


                Private Discovery Threat Considerations
             draft-cheshire-dnssd-privacy-considerations-01

Abstract

   This document provides a framework for evaluating and comparing
   solutions for privacy-respecting discovery mechanisms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 17, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Cheshire                  Expires May 17, 2018                  [Page 1]


Internet-Draft   Private Discovery Threat Considerations   November 2017


1.  Introduction

   When AppleTalk was introduced in 1986, privacy concerns were not
   foremost in most people's minds.  The fact that a printer was
   offering printing service was not considered a secret, and the fact
   that a computer was seeking printing service was not considered a
   secret.  The fact that the computer could discover the printer
   without expert configuration was considered remarkable.

   Thirty years later, the landscape has changed.  We now have many more
   network service types, and mobile wireless devices offering and
   consuming those services are common.  Those mobile wireless devices
   and the services they offer or use often involve sensitive financial
   or medical data.  Furthermore, the ubiquity of such mobile wireless
   devices makes them an attractive target for mischievous or outright
   criminal activity.  The fact that a person's smartphone is
   communicating with their implanted glucose monitor or insulin pump is
   not something that should be public information.

   Hence there is now a need for discovery mechanisms that utilize
   privacy-preserving techniques.  There have been various different
   efforts to address this, but they tend to offer solutions based on
   assumptions of what privacy aspects are important, without
   articulating what those assumptions are.  Without knowing the
   assumptions and design goals of a particular proposal it is hard to
   evaluate whether that proposal meets those goals, or indeed whether
   they are the right goals.

   Without advocating for any particular solution, this document
   presents an overview of the various aspects of device discovery and
   service discovery, and outlines the privacy concerns of each.  Any
   given proposal may not address all possible privacy concerns.
   Depending on the scenario, it may not be necessary to address every
   privacy concern.  Indeed, it may turn out to be impossible, or at
   least impractical, to address all possible privacy concerns.  This
   document provides a framework to help evaluate whether a given
   solution meets the privacy needs of some particular usage scenario.














Cheshire                  Expires May 17, 2018                  [Page 2]


Internet-Draft   Private Discovery Threat Considerations   November 2017


2.  Discovery Operations

   Device discovery and service discovery involve three principal
   operations:

   1.  Offer
   2.  Discover
   3.  Use

   The "Offer" operation is how a device offers a service on the
   network.  Typically this involves, using today's terminology,
   (a) a "listening" UDP or TCP socket, which accepts incoming packets
   or connections, and (b) a way of advertising to other local and
   remote devices what kind of service is being offered, its name, and
   other metadata including how to reach it.  Observe that there are
   three levels of information in use here: (i) the type of service,
   (ii) the name of the particular instance of that type of service, and
   (iii) the operational details of how to connect to and make use of
   that particular instance.

   The "Discover" operation is how a client device learns what service
   instances are being offered (by local devices, and/or remote devices,
   depending on the discovery mechanism being used).  Typically a client
   device knows what kind of service it is seeking, and wants to
   discover named instances of that service.  The "Discover" operation
   is linking information level (i) type of service, with information
   level (ii) names of specific instances offering that type of service.
   The "Discover" operation can be viewed as providing a little
   information (just the name) about many different instances.  In terms
   of complexity and efficiency, it's a 1 x n operation, getting one
   piece of information about n instances.

   The "Use" operation is how a client device requests additional
   information (IP address(es), port number, and possibly other
   metadata), and then uses this information to communicate with the
   service instance and make use of the service it offers.  The "Use"
   operation is linking information level (ii) specific instance name,
   with information level (iii) detailed information about that
   individual instance.  The "Use" operation can be viewed as providing
   a lot of information about one particular instance.  In terms of
   complexity and efficiency, it's an m x 1 operation, getting m pieces
   of information about 1 instance, and then proceeding to use that
   instance.

   All three operations, and the three levels of information they use,
   need to be considered from a privacy perspective.





Cheshire                  Expires May 17, 2018                  [Page 3]


Internet-Draft   Private Discovery Threat Considerations   November 2017


   Note that some discovery mechanisms conflate "Discover" and "Use"
   into a single operation.  Instead of requesting a little information
   about a lot of instances, or a lot of information about a single
   instance, they are only able to request everything about everything.
   They replace a 1 x n operation and an m x 1 operation with a combined
   m x n operation, always requesting m pieces of information each about
   n different instances.












































Cheshire                  Expires May 17, 2018                  [Page 4]


Internet-Draft   Private Discovery Threat Considerations   November 2017


3.  Trust Granularity

   When we talk about entities trusting other entities, what entities
   are we talking about?

   Are the entities physical devices, like a smartphone or laptop
   computer?

   Are the entities human users?  If a device like a laptop computer has
   multiple users, we should not assume that because one user is
   authorized to discover certain services that means that all other
   users of that laptop are also authorized to discover those services.

   Are the entities software applications?  If a device like a
   smartphone has multiple apps installed, we should not assume that
   because one app is authorized to discover certain services that means
   that all other apps on that smartphone are also authorized to
   discover those services.  For example, just because a medical app on
   a smartphone is authorized to discover and communicate with the
   user's medical devices such as an implanted insulin monitor, that
   doesn't mean that social network apps or games on that same
   smartphone are also authorized to discover and communicate with those
   medical devices.

   Note that when the text above talks about a user or app being
   "authorized" we're not talking about authorization controls being
   enforced by the laptop or smartphone.  Controls enforced by the
   laptop or smartphone operating system are appropriate and have their
   place, but the kind of authorization controls we're talking about
   here are enforced by the entity being discovered.  When the entity
   being discovered receives a query from an authorized source, it
   answers the query.  When the entity being discovered receives a query
   from an unauthorized source, it does not answer the query.  The
   important question is the granularity of the "source" referred to --
   is it a physical device, a user, or an app?  (This analysis
   presupposes that the host operating system on the device has
   sufficient memory protection and access controls to protect one
   user's secret key material from being accessed and abused by another
   user, or one app's secret key material from being accessed and abused
   by another app.  For a device without such protection, only the per-
   device granularity of trust is applicable.)










Cheshire                  Expires May 17, 2018                  [Page 5]


Internet-Draft   Private Discovery Threat Considerations   November 2017


4.  Desirable Security Properties

   For each of the operations and information levels described above, we
   need to consider what threats we are concerned about.

   Authenticity & Integrity
      Can we trust the information we receive?  Has it been modified in
      flight by an adversary?  Do we trust the source of the
      information?

   Confidentiality
      Who can read the information sent in messages?  Ideally this
      should only be the appropriate trusted parties, but it can be hard
      to define who "the appropriate trusted parties" are.  The
      "Discover" operation in particular is often used to discover new
      entities that the device did not previously know about.  It may be
      tricky to work out how a device can have an established trust
      relationship with a new entity it has never previously
      communicated with.

   Anonymity
      Does the information exchange reveal the identity of either
      participant?  In this context "identity" can mean things like the
      name, email address, or phone number of the human user.  It could
      mean things like the hostname or MAC address of the device.  Even
      when information is authenticated and confidential, there can be
      unexpected sources of information leakage.  For example, if
      suitable precautions are not taken, the source MAC address in data
      packets can reveal the identity of the device manufacturer, which
      can yield clues about the nature of the device.

   Resistance to Dictionary Attacks
      It can be tempting to use simple one-way hash functions to obscure
      sensitive identifiers.  This transforms a sensitive unique
      identifier such as an email address into a scrambled (but still
      unique) identifier.  Unfortunately simple solutions may be
      vulnerable to offline dictionary attacks.  Given a scrambled
      unique identifier, it may be possible to do a brute-force attack,
      trying billions of known and speculative email addresses until a
      match is found.

   Resistance to Tracking
      In today's world, we have to be sensitive to any unchanging unique
      identifier, no matter how thoroughly and irreversibly scrambled it
      may be.  Even though an attacker may not be able to divine the
      origin of a scrambled unique identifier, the unchanging unique
      identifier may still be correlated with other things.  If a given
      unchanging unique identifier appears on a cafe network every



Cheshire                  Expires May 17, 2018                  [Page 6]


Internet-Draft   Private Discovery Threat Considerations   November 2017


      morning when a certain person comes in to get coffee, then with
      some certainty that unchanging unique identifier can be associated
      with that person, and used to track their movements around the
      city for the rest of their workday.  Consequently, in cases where
      this threat is a concern, all cleartext identifiers used on the
      network need to be rotated according to some policy, so that a
      given identifier is not reused for too long or in different
      locations.  These changing identifiers can be decoded by trusted
      entities, but are meaningless to anyone else.

   Resistance to Message Linking
      Is it possible to link or correlate exchanges across discovery
      operations?  For example, do Discovery messages reveal information
      about future Use messages, or vice versa?  This can be done via
      sender MAC address, for example.  An adversary can use linkability
      information to de-anonymize service users or providers, even in
      the event that, individually, no information leaks from any
      particular message alone (e.g., because it's encrypted in
      transit).  For example, even if persistent identifiers are rotated
      periodically, if all identifiers are not rotated in unison then
      the overlap period can be used to track the user across identifier
      rotations.

   Resistance to Denial-of-Service Attack
      In any protocol where the receiver of messages has to perform
      cryptographic operations on those messages, there is a risk of a
      brute-force flooding attack causing the receiver to expend
      excessive amounts of CPU time (and battery power) just processing
      and discarding those messages.






















Cheshire                  Expires May 17, 2018                  [Page 7]


Internet-Draft   Private Discovery Threat Considerations   November 2017


5.  Other Operational Requirements

5.1.  Power Management

   Many modern devices, especially battery-powered devices, use power
   management techniques to conserve energy.  One such technique is for
   a device to transfer information about itself to a proxy, which will
   act on behalf of the device for some functions, while the device
   itself goes to sleep to reduce power consumption.  When the proxy
   determines that some action is required which only the device itself
   can perform, the proxy may have some way (such as Ethernet "Magic
   Packet") to wake the device.

   In many cases, the device may not trust the network proxy
   sufficiently to share all its confidential key material with the
   proxy.  This poses challenges for combining private discovery that
   relies on per-query cryptographic operations, with energy-saving
   techniques that rely on having (somewhat untrusted) network proxies
   answer queries on behalf of sleeping devices.

5.2.  Protocol Efficiency

   Creating a discovery protocol that has the desired security
   properties may result in a design that is not efficient.  To perform
   the necessary operations the protocol may need to send and receive a
   large number of network packets.  This may consume an unreasonable
   amount of network capacity (particularly problematic when it's shared
   wireless spectrum), cause an unnecessary level of power consumption
   (particularly problematic on battery devices) and may result in the
   discovery process being slow.

   It is a difficult challenge to design a discovery protocol that has
   the property of obscuring the details of what it is doing from
   unauthorized observers, while also managing to do that quickly and
   efficiently.

5.3.  Secure Initialization

   One of the challenges implicit in the preceding discussions is that
   whenever we discuss "trusted entities" versus "untrusted entities",
   there needs to be some way that trust is initially established, to
   convert an "untrusted entity" into a "trusted entity".

   One way to establish trust between two entities is to trust a third
   party to make that determination for us.  For example, the X.509
   certificates used by TLS and HTTPS web browsing are based on the
   model of trusting a third party to tell us who to trust.  There are
   some difficulties in using this model for establishing trust for



Cheshire                  Expires May 17, 2018                  [Page 8]


Internet-Draft   Private Discovery Threat Considerations   November 2017


   service discovery uses.  If we want to print our tax returns or
   medical documents on "our" printer, then we need to know which
   printer on the network we can trust be be "our" printer.  All of the
   printers we discover on the network may be legitimate printers made
   by legitimate printer manufacturers, but not all of them are "our"
   printer.  A third-party certificate authority cannot tell us which
   one of the printers is ours.

   Another common way to establish a trust relationship is Trust On
   First Use (TOFU), as used by ssh.  The first usage is a Leap Of
   Faith, but after that public keys are exchanged and at least we can
   confirm that subsequent communications are with the same entity.  In
   today's world, where there may be attackers present even at that
   first use, it would be preferable to be able to establish a trust
   relationship without requiring an initial Leap Of Faith.

   Techniques now exist for securely establishing a trust relationship
   without requiring an initial Leap Of Faith.  Trust can be established
   securely using a short passphrase or PIN with cryptographic
   algorithms such as Secure Remote Password (SRP) [RFC5054] or a
   Password Authenticated Key Exchange like J-PAKE [RFC8236] using a
   Schnorr Non-interactive Zero-Knowledge Proof [RFC8235].

   Such techniques require a user to enter the correct passphrase or PIN
   in order for the cryptographic algorithms to establish working
   communication.  This avoids the human tendency to simply press the
   "OK" button when asked if they want to do something on their
   electronic device.  It removes the human fallibility element from the
   equation, and avoids the human users inadvertently sabotaging their
   own security.

   Using these techniques, if a user tries to print their tax return on
   a printer they've never used before (even though the name looks
   right) they'll be prompted to enter a pairing PIN, and the user
   *cannot* ignore that warning.  They can't just press an "OK" button.
   They have to walk to the printer and read the displayed PIN and enter
   it.  And if the intended printer is not displaying a pairing PIN, or
   is displaying a different pairing PIN, that means the user may be
   being spoofed, and the connection will not succeed, and the failure
   will not reveal any secret information to the attacker.  As much as
   the human desires to "just give me an OK button to make it print"
   (and the attacker desires them to click that OK button too) the
   cryptographic algorithms do not give the user the ability to opt out
   of the security, and consequently do not give the attacker any way to
   persuade the user to opt out of the security protections.






Cheshire                  Expires May 17, 2018                  [Page 9]


Internet-Draft   Private Discovery Threat Considerations   November 2017


6.  Informative References

   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", RFC 5054, DOI 10.17487/RFC5054, November
              2007, <https://www.rfc-editor.org/info/rfc5054>.

   [RFC8235]  Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge
              Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017,
              <https://www.rfc-editor.org/info/rfc8235>.

   [RFC8236]  Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange
              by Juggling", RFC 8236, DOI 10.17487/RFC8236, September
              2017, <https://www.rfc-editor.org/info/rfc8236>.

Author's Address

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com


























Cheshire                  Expires May 17, 2018                 [Page 10]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/