DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements
draft-ietf-dnssd-prireq-08

amp; Freshness

   Can devices (both servers and clients) trust the information they
   receive?  Has it been modified in flight by an adversary?  Can
   devices trust the source of the information?  Is the source of
   information fresh, i.e., not replayed?  Freshness may or may not be
   required depending on whether the discovery process is meant to be
   online.  In some cases, publishing discovery information to a shared
   directory or registry, rather than to each online recipient through a
   broadcast channel, may suffice.

3.3.2.  Confidentiality

   Confidentiality is about restricting information access to only
   authorized individuals.  Ideally this should only be the appropriate
   trusted parties, though it can be challenging to define who are "the
   appropriate trusted parties."  In some use cases, this may mean that
   only mutually authenticated and trusting clients and servers can read
   messages sent for one another.  The process of service discovery 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

Huitema & Kaiser       Expires September 13, 2020              [Page 12]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

   can have an established trust relationship with a new entity it has
   never previously communicated with.

3.3.3.  Resistance to Dictionary Attacks

   It can be tempting to use (publicly computable) 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.

3.3.4.  Resistance to Denial-of-Service Attacks

   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, where appliciable, battery power just
   processing and discarding those messages.

   Also, amplification attacks have to be taken into consideration.
   Messages with larger payloads should only be sent as an answer to a
   query sent by a verified client.

3.3.5.  Resistance to Sender Impersonation

   Sender impersonation is an attack wherein messages such as service
   offers are forged by entities who do not possess the corresponding
   secret key material.  These attacks may be used to learn the identity
   of a communicating party, actively or passively.

3.3.6.  Sender Deniability

   Deniability of sender activity, e.g., of broadcasting a discovery
   request, may be desirable or necessary in some use cases.  This
   property ensures that eavesdroppers cannot prove senders issued a
   specific message destined for one or more peers.

3.4.  Operational Considerations

3.4.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

Huitema & Kaiser       Expires September 13, 2020              [Page 13]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

   can perform, the proxy may have some way to wake the device, as
   described for example in [SLEEP-PROXY].

   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.

3.4.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, or require an inordinate amount of
   multicast transmissions.  This may consume an unreasonable amount of
   network capacity, particularly problematic when it is a shared
   wireless spectrum.  Further, it may cause an unnecessary level of
   power consumption which is 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 perform efficiently.

3.4.3.  Secure Initialization and Trust Models

   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".

   The purpose of this document is not to define the specific way in
   which trust can be established.  Protocol designers may rely on a
   number of existing technologies, including PKI, Trust On First Use
   (TOFU), or 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].

   Protocol designers should consider a specific usability pitfall when
   trust is established immediately prior to performing discovery.
   Users will have a tendency to "click OK" in order to achieve their
   task.  This implicit vulnerability is avoided if the trust
   establishment requires more significant participation of the user,
   such as entering a password or PIN.

Huitema & Kaiser       Expires September 13, 2020              [Page 14]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

3.4.4.  External Dependencies

   Trust establishment may depend on external parties.  Optionally, this
   might involve synchronous communication.  Systems which have such a
   dependency may be attacked by interfering with communication to
   external dependencies.  Where possible, such dependencies should be
   minimized.  Local trust models are best for secure initialization in
   the presence of active attackers.

4.  Requirements for a DNS-SD Privacy Extension

   Given the considerations discussed in the previous sections, we state
   requirements for privacy preserving DNS-SD in the following
   subsections.

   Defining a solution according to these requirements is intended to
   lead to a solution that does not transmit privacy-violating DNS-SD
   messages and further does not open pathways to new attacks against
   the operation of DNS-SD.

   However, while this document gives advice on which privacy protecting
   mechanisms should be used on deeper-layer network protocols and on
   how to actually connect to services in a privacy-preserving way,
   stating corresponding requirements is out of the scope of this
   document.  To mitigate attacks against privacy on lower layers, both
   servers and clients must use privacy options available at lower
   layers, and for example avoid publishing static IPv4 or IPv6
   addresses, or static IEEE 802 MAC addresses.  For services advertised
   on a single network link, link local IP addresses should be used; see
   [RFC3927] and [RFC4291] for IPv4 and IPv6, respectively.  Static
   servers advertising services globally via DNS can hide their IP
   addresses from unauthorized clients using the split mode topology
   shown in [I-D.ietf-tls-esni].  Hiding static MAC addresses can be
   achieved via MAC address randomization (see [RFC7844]).

4.1.  Private Client Requirements

   For all three scenarios described in Section 3.1, client privacy
   requires DNS-SD messages to:

   1.  Avoid disclosure of the client's identity, either directly or via
       inference, to nodes other than select servers.

   2.  Avoid exposure of linkable identifiers that allow tracing client
       devices.

   3.  Avoid disclosure of the client's interest in specific service
       instances or service types to nodes other than select servers.

Huitema & Kaiser       Expires September 13, 2020              [Page 15]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

   When listing and resolving services via current DNS-SD deployments,
   clients typically disclose their interest in specific services types
   and specific instances of these types, respectively.

   In addition to the exposure and disclosure risks noted above,
   protocols and implementations will have to consider fingerprinting
   attacks (see Section 3.2.5) that could retrieve similar information.

4.2.  Private Server Requirements

   Servers like the "printer" discussed in scenario 1 are public, but
   the servers discussed in scenarios 2 and 3 are by essence private.
   Server privacy requires DNS-SD messages to:

   1.  Avoid disclosure of the server's identity, either directly or via
       inference, to nodes other than authorized clients.  In
       particular, Servers must avoid publishing static identifiers such
       as host names or service names.  When those fields are required
       by the protocol, servers should publish randomized values.  (See
       [RFC8117] for a discussion of host names.)

   2.  Avoid exposure of linkable identifiers that allow tracing
       servers.

   3.  Avoid disclosure to unauthorized clients of service instance
       names or service types of offered services.

   4.  Avoid disclosure to unauthorized clients of information about the
       services they offer.

   5.  Avoid disclosure of static IPv4 or IPv6 addresses.

   When offering services via current DNS-SD deployments, servers
   typically disclose their hostnames (SRV, A/AAAA), instance names of
   offered services (PRT, SRV), and information about services (TXT).
   Heeding these requirements protects a server's privacy on the DNS-SD
   level.

   The current DNS-SD user interfaces present the list of discovered
   service names to the users, and let them pick a service from the
   list.  Using random identifiers for service names renders that UI
   flow unusable.  Privacy-respecting discovery protocols will have to
   solve this issue, for example by presenting authenticated or
   decrypted service names instead of the randomized values.

Huitema & Kaiser       Expires September 13, 2020              [Page 16]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

4.3.  Security and Operation

   In order to be secure and feasible, a DNS-SD privacy extension needs
   to consider security and operational requirements including:

   1.  Avoiding significant CPU overhead on nodes or significantly
       higher network load.  Such overhead or load would make nodes
       vulnerable to denial of service attacks.  Further, it would
       increase power consumption which is damaging for IoT devices.

   2.  Avoiding designs in which a small message can trigger a large
       amount of traffic towards an unverified address, as this could be
       exploited in amplification attacks.

5.  IANA Considerations

   This draft does not require any IANA action.

6.  Acknowledgments

   This draft incorporates many contributions from Stuart Cheshire and
   Chris Wood.  Thanks to Florian Adamsky for extensive review and
   suggestions on the organization of the threat model.  Thanks to Barry
   Leiba for an extensive review.  Thanks to Roman Danyliw, Ben Kaduk,
   Adam Roach and Alissa Cooper for their comments during IESG review.

7.  References

7.1.  Normative References

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

7.2.  Informative References

   [I-D.ietf-dnssd-srp]
              Cheshire, S. and T. Lemon, "Service Registration Protocol
              for DNS-Based Service Discovery", draft-ietf-dnssd-srp-02
              (work in progress), July 2019.

Huitema & Kaiser       Expires September 13, 2020              [Page 17]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

   [I-D.ietf-tls-esni]
              Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
              "Encrypted Server Name Indication for TLS 1.3", draft-
              ietf-tls-esni-05 (work in progress), November 2019.

   [K17]      Kaiser, D., "Efficient Privacy-Preserving
              Configurationless Service Discovery Supporting Multi-Link
              Networks", 2017,
              <http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.

   [KW14a]    Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast
              DNS Service Discovery", DOI 10.1109/TrustCom.2014.107,
              2014, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=7011331>.

   [KW14b]    Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving
              Multicast DNS Service Discovery",
              DOI 10.1109/HPCC.2014.141, 2014,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=7056899>.

   [RFC1033]  Lottor, M., "Domain Administrators Operations Guide",
              RFC 1033, DOI 10.17487/RFC1033, November 1987,
              <https://www.rfc-editor.org/info/rfc1033>.

   [RFC1034]  Mockapetris, P., "
   registry [RFC6020].  Following the format in [RFC6020], the following
   registrations are requested:

Jethanandani & Watsen     Expires 4 August 2024                [Page 19]
Internet-Draft        HTTPS Notification Transport         February 2024

  name:      ietf-subscribed-notif-receivers
  namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-notif-receivers
  prefix:    snr
  reference: RFC XXXX

  name:      ietf-https-notif-transport
  namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif-transport
  prefix:    hnt
  reference: RFC XXXX

8.3.  Registration of 'yang-notif' URN Sub-namespace

   This document requests that IANA register a new URN Sub-namespace
   within the "IETF URN Sub-namespace for Registered Protocol Parameter
   Identifiers" registry defined in [RFC3553].

   Registry Name: yang-notif
   Specification: RFC XXXX
   Repository: "YANG Notifications" registry

8.4.  Registration of 'https' URN Sub-namespace

   This document requests that IANA register a new URN Sub-namespace
   within the "YANG Notifications" registry group defined in [RFC3553].

   Registry Name: https-capability
   Specification: RFC XXXX
   Repository: "Capabilities for HTTPS Notification Receivers" registry

   The following note shall be at the top of the registry:

   This registry defines capabilities that can be
   supported by HTTPS-based notification receivers.

   The fields for each registry are:

   *  URN

      -  The name of the URN (required).

      -  The URN must conform to the syntax described by [RFC8141].

      -  The URN must begin with the string "urn:ietf:params:yang-
         notif:https-capability".

   *  Reference

      -  The RFC that defined the URN.

Jethanandani & Watsen     Expires 4 August 2024                [Page 20]
Internet-Draft        HTTPS Notification Transport         February 2024

      -  The RFC must be in the form "RFC <Number>: <Title>.

   *  Description

      -  An arbitrary description of the capability.

      -  The description should be no more than a few sentences.

      -  The description is to be in English, but may contain UTF-8
         characters as may be needed in some cases.

   The update policy is "RFC Required".

   Following is the initial assignment for this registry:

Record:
   URN:         urn:ietf:params:yang-notif:https-capability:encoding:json
   Reference:   RFC XXXX:An HTTPS-based Transport for YANG Notifications
   Description: Identifies support for JSON-encoded notifications.

Record:
   URN:         urn:ietf:params:yang-notif:https-capability:encoding:xml
   Reference:   RFC XXXX:An HTTPS-based Transport for YANG Notifications
   Description: Identifies support for XML-encoded notifications.

Record:
   URN:         urn:ietf:params:yang-notif:https-capability:sub-notif
   Reference:   RFC XXXX:An HTTPS-based Transport for YANG Notifications
   Description: Identifies support for state machine described in
                RFC 8639, enabling the publisher to send, e.g., the
                "subscription-started" notification.

9.  References

9.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
              IETF URN Sub-namespace for Registered Protocol
              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
              2003, <https://www.rfc-editor.org/info/rfc3553>.

Jethanandani & Watsen     Expires 4 August 2024                [Page 21]
Internet-Draft        HTTPS Notification Transport         February 2024

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
              <https://www.rfc-editor.org/info/rfc5277>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
              DOI 10.17487/RFC7303, July 2014,
              <https://www.rfc-editor.org/info/rfc7303>.

   [RFC7407]  Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
              SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
              December 2014, <https://www.rfc-editor.org/info/rfc7407>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Jethanandani & Watsen     Expires 4 August 2024                [Page 22]
Internet-Draft        HTTPS Notification Transport         February 2024

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
              E., and A. Tripathy, "Subscription to YANG Notifications",
              RFC 8639, DOI 10.17487/RFC8639, September 2019,
              <https://www.rfc-editor.org/info/rfc8639>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/info/rfc9112>.

   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/info/rfc9113>.

   [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/info/rfc9114>.

Jethanandani & Watsen     Expires 4 August 2024                [Page 23]
Internet-Draft        HTTPS Notification Transport         February 2024

   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

   [I-D.ietf-netconf-http-client-server]
              Watsen, K., "YANG Groupings for HTTP 1.1/2.0 Clients and
              HTTP Servers", Work in Progress, Internet-Draft, draft-
              ietf-netconf-http-client-server-15, 26 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
              http-client-server-15>.

   [I-D.ietf-netconf-tls-client-server]
              Watsen, K., "YANG Groupings for TLS Clients and TLS
              Servers", Work in Progress, Internet-Draft, draft-ietf-
              netconf-tls-client-server-36, 29 January 2024,
              "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              DOI 10.17487/RFC3927, May 2005,
              <https://www.rfc-editor.org/info/rfc3927>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

Huitema & Kaiser       Expires September 13, 2020              [Page 18]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

   [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>.

   [RFC7558]  Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
              "Requirements for Scalable DNS-Based Service Discovery
              (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
              DOI 10.17487/RFC7558, July 2015,
              <https://www.rfc-editor.org/info/rfc7558>.

   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
              Profiles for DHCP Clients", RFC 7844,
              DOI 10.17487/RFC7844, May 2016,
              <https://www.rfc-editor.org/info/rfc7844>.

   [RFC8117]  Huitema, C., Thaler, D., and R. Winter, "Current Hostname
              Practice Considered Harmful", RFC 8117,
              DOI 10.17487/RFC8117, March 2017,
              <https://www.rfc-editor.org/info/rfc8117>.

   [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>.

   [SLEEP-PROXY]
              Cheshire, S., "Understanding Sleep Proxy Service", 2009,
              <http://stuartcheshire.org/SleepProxy/index.html>.

Authors' Addresses

   Christian Huitema
   Private Octopus Inc.
   Friday Harbor, WA  98250
   U.S.A.

   Email: huitema@huitema.net
   URI:   http://privateoctopus.com/

Huitema & Kaiser       Expires September 13, 2020              [Page 19]
Internet-Draft         DNS-SD Privacy Requirements            March 2020

   Daniel Kaiser
   University of Luxembourg
   6, avenue de la Fonte
   Esch-sur-Alzette  4364
   Luxembourg

   Email: daniel.kaiser@uni.lu
   URI:   https://secan-lab.uni.lu/

Huitema & Kaiser       Expires September 13, 2020              [Page 20]