draft-huitema-dnssd-tls-privacy.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY rfc1033 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1033.xml'>
<!ENTITY rfc1034 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc2045 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml'>
<!ENTITY rfc2119 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2782 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml'>
<!ENTITY rfc4055 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml'>
<!ENTITY rfc4075 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4075.xml'>
<!ENTITY rfc4279 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4279.xml'>
<!ENTITY rfc4648 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml'>
<!ENTITY rfc5246 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc6762 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml'>
<!ENTITY rfc6763 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml'>
<!ENTITY rfc7626 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7626.xml'>
<!ENTITY rfc7844 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml'>
<!ENTITY rfc7858 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml'>
<!ENTITY rfc8117 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8117.xml'>
<!ENTITY rfc8094 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml'>
<!ENTITY rfc8117 PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8117.xml'>
<!ENTITY rfc8446 PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">

<!ENTITY I-D.ietf-dnssd-privacyscaling PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnssd-privacyscaling">
<!ENTITY I-D.ietf-dnssd-prireq PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnssd-prireq">
<!ENTITY I-D.ietf-tls-dtls13 PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13">
<!ENTITY I-D.ietf-tls-esni PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni">
<!ENTITY I-D.ietf-quic-transport PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-transport">
<!ENTITY I-D.ietf-quic-tls PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-tls">

<!ENTITY I-D.huitema-quic-dnsoquic PUBLIC ''  
   "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.huitema-quic-dnsoquic">

<!ENTITY kw14a PUBLIC ''
   "references/reference.kw14a.xml">
<!ENTITY kw14b PUBLIC ''
   "references/reference.kw14b.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>

<rfc category="std" 
     docName="draft-huitema-dnssd-tls-privacy-01"
     ipr="trust200902">

<front>
    <title abbrev="TLS/ESNI Based Private Discovery">
      Private Discovery with TLS-ESNI
    </title>

   <author fullname="Christian Huitema" initials="C." surname="Huitema">
      <organization>Private Octopus Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>Friday Harbor</city>
          <code>98250</code>
          <region>WA</region>
          <country>U.S.A.</country>
        </postal>
        <email>huitema@huitema.net</email>
        <uri>http://privateoctopus.com/</uri>
      </address>
    </author>


   <author fullname="Daniel Kaiser" initials="D." surname="Kaiser">
      <organization>University of Luxembourg</organization>
      <address>
        <postal>
          <street>6, avenue de la Fonte</street>
          <city>Esch-sur-Alzette</city>
          <code>4364</code>
          <region></region>
          <country>Luxembourg</country>
        </postal>
        <email>daniel.kaiser@uni.lu</email>
        <uri>https://secan-lab.uni.lu/</uri>
      </address>
    </author>

    <date year="2019" />

    <abstract>
        <t>
DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services.
This information includes host names, network parameters, and possibly a further description of the corresponding service instance.
Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot,
a serious privacy problem arises.
</t>
<t>
We propose to solve this problem by developing a private discovery profile for UDP based transports using TLS,
such as DTLS and QUIC. The profile is based on using the Encrypted SNI extension. We also define a standalone
private discovery service, that can be combined with arbitrary applications in the same way as DNS-SD.
</t>
    </abstract>
</front>

<middle>
<section title="Introduction">
<t>
DNS-SD <xref target="RFC6763" /> over mDNS <xref target="RFC6762" /> enables configurationless 
service discovery in local networks.
It is very convenient for users, but it requires the public exposure 
of the offering and requesting identities along with information about the offered and 
requested services.
Parts of the published information can seriously breach the user's privacy.
These privacy issues and potential solutions are discussed in <xref target="KW14a" />
and <xref target="KW14b" />.
</t>
<t>
When analyzing these scenarios in <xref target="I-D.ietf-dnssd-prireq" />, we find that
the DNS-SD messages leak identifying information such as the instance name,
the host name or service properties. 
</t>
<t>
In this document, we propose a discovery solution that can replace DNS-SD in simple deployment
scenarios, with the following characteristics:
</t>
<t>
<list style="numbers">
<t>
We only target discovery of peers on the same local network, using multicast. We
make no attempt at compatibility with the server based solutions such as DNSSD
over Unicast DNS <xref target="RFC6763" />.
</t>
<t>
We do not attempt to keep the same formats as mDNS <xref target="RFC6762" />.
</t>
<t>
We assume a solution that can be integrated in an application, without dependency
on system support.
</t>
</list>
</t>
<t>
The proposed solution aligns with TLS 1.3 <xref target="RFC8446"/>, and
specifically with transports of TLS over UDP, such as DTLS <xref target="I-D.ietf-tls-dtls13"/>
or QUIC <xref target="I-D.ietf-quic-transport" />.
The solution uses SNI encryption <xref target="I-D.ietf-tls-esni" />.
</t>
<t>
The solution assumes that entities who want to be privately discovered maintain
an asymmetric discovery key pair. The public component of that discovery key pair
and the service name of the entity are provisioned to authorized discovery
clients. In this document, we will refer to this public component as the
"Discovery Key" of the server. When needed, we will refer to the private
component of the key pair as the "Discovery Private Key".
</t>
<section title="Requirements">
<t>
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in <xref target="RFC2119" />.
</t>
</section>
</section>

<section title="Discovery Service Using TLS and ESNI" anchor="esni-design" >
<t>
In the proposed solution, the first packet of a TLS-based UDP transport is
broadcast or multicast over the local network. This packet carries the TLS 1.3 
ClientHello message, including an Encrypted SNI (ESNI) extension. The ESNI
is encrypted with the Discovery Key of the requested service.
</t>
<t>
Services that are ready to be discovered listen on the broadcast or
multicast address and check whether the received packets contain a TLS 1.3
ClientHello Message and an ESNI extension. If the extension can be
decrypted with the Private Discovery Key of the local service, they
set up a connection.
</t>
<t>
This mechanism only works with TLS based protocols operating over UDP, such
as DTLS or QUIC.
</t>
<section title="Discovery Key" anchor="esni-key" >
<t>
Private discovery relies on the privacy of the server Discovery Key, which
is used to encrypt the target server name carried in the ESNI extension.
Clients can only discover a server if they know the server's Discovery Key.
Servers receiving a properly encrypted discovery request do not know
the identity of the client issuing the request, but they know that the
client belongs to a group authorized to perform the discovery.
</t>
<t>
In the ESNI based specification, the server's Discovery Key plays the
same role as the ESNI Encryption Key of the client facing server, but
a major difference is that the Discovery Key is kept private.
According to standard ESNI, the client facing server publishes an ESNI encryption
key in the DNS. In contrast, the Discovery Key MUST NOT be publicly
available in the DNS.
</t>
<t>
The discovery key is passed to the peer in exactly the same format as ESNI:
</t>
<t>
<figure>
<artwork>
    struct {
        uint8 checksum[4];
        KeyShareEntry keys&lt;4..2^16-1>;
        CipherSuite cipher_suites&lt;2..2^16-2>;
        uint16 padded_length;
        uint64 not_before;
        uint64 not_after;
        Extension extensions&lt;0..2^16-1>;
    } ESNIKeys;
</artwork>
</figure>
</t>
<t>
This document does not discuss how the Discovery Key is provisioned to
authorized discovery clients.
</t>
<t>
The ESNI extension design assumes that several services are available through
a single client facing server. These different services have different SNI
values and length. ESNI pads these SNI to a padded length specified for the
client facing server, ensuring that third parties cannot infer the
identity of the service from the length of the extension. In our
design, requests for multiple services are sent over multicast. If different
services used different padding length, third parties could infer the
service identity from the ESNI length. To prevent this information
leakage, services participating in private discovery MUST set the padded
length to exactly 128 bytes.
</t>
</section>

<section title="ESNI Extension for Discovery" anchor="esni-verif" >
<t>
The ESNI extension is defined in <xref target="I-D.ietf-tls-esni" /> as:
</t>
<t>
<figure>
<artwork>
      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest&lt;0..2^16-1>;
          opaque encrypted_sni&lt;0..2^16-1>;
      } ClientEncryptedSNI;
</artwork>
</figure>
</t>
<t>
In standard ESNI usage, the "record_digest" identifies the ESNI Encryption Key.
Clients using private discovery MUST leave the "record_digest" empty, and
encode it as a zero-length binary string. The ESNI Encryption Key will be
the Discovery Key of the target server.
</t>
<t>
The KeyShareEntry is set in accordance with the ESNI specification. It is combined
with the server Discovery Key to encrypt the SNI. According to the ESNI
specification, the encrypted structure contains:
</t>
<t>
<figure>
<artwork>
      struct {
          ServerNameList sni;
          opaque zeros[ESNIKeys.padded_length - length(sni)];
      } PaddedServerNameList;

      struct {
          uint8 nonce[16];
          PaddedServerNameList realSNI;
      } ClientESNIInner;
</artwork>
</figure>
</t>
<t>
Servers that receive the extension as part of private discovery attempt to decrypt the
value using their Private Discovery Key. If the decryption succeeds, and if
the decrypted SNI corresponds to the expected value, the server will accept
the discovery request. 
</t>
</section>

<section title="Integration with DTLS" >
<t>
The message flows of DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/> all start
with the client sending a TLS ClientHello message. The following figure
presents a simple DTLS flow using the ESNI extension for private discovery:
</t>
<t>
<figure>
<artwork>
Client                                             Server

ClientHello                                              +----------+
 + key_share*                                            | Flight 1 |
 + ESNI                 -------->                        +----------+

                                            ServerHello
                                           + key_share*  +----------+
                                  {EncryptedExtensions}  | Flight 2 |
                                                 {ESNI}  +----------+
                                         {Certificate*}
                        &lt;--------            {Finished}
                                    [Application Data*]

                                                         +----------+
                                                         | Flight 3 |
 {Finished}             -------->                        +----------+
 [Application Data]

                                                         +----------+
                        &lt;--------                 [Ack]  | Flight 4 |
                                    [Application Data*]  +----------+

 [Application Data]     &lt;------->   [Application Data]
</artwork>
</figure>
</t>
<t>
The first flight consists of a single UDP packet. In classic DTLS, this would be
sent to the IP address and UDP port chosen for the application. Instead, the client using
private discovery MUST sent this to the "private discovery" multicast address
defined in <xref target="iana" /> and to
the UDP port chosen for the application.
</t>
<t>
The multicast message sent by the client will be received by many servers.
The servers using private discovery MUST verify that the ESNI extension is
present. If it is present, each server attempts to decrypt the ESNI extension
using the local private discovery key, as specified in <xref target="esni-verif"/>.
If the verification succeeds, the server proceeds with the connection, and
sends the second flight of DTLS packets to the IP address and UDP port
from which it received the client's first flight.
</t>
<t>
The client receiving the second flight of messages processes them as specified in
DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/>. The client MUST verify that the ESNI
extension is present, and matches the expected value as specified in 
<xref target="esni-verif"/>. If the ESNI extension is absent or does not
pass verification, the entire flight MUST be ignored. If the verification
succeeds, the client remembers the IP address and UDP port of the server,
and uses it for the reminder of the session.
</t>
<t>
A successful ESNI exchange demonstrates to the server that the client has knowledge of
the server discovery key, and to the client that the server is in
possession of the corresponding private discovery key. This is meant to restrict
access to a subset of the client and server population, but does not replace the
need for server authentication and optional client authentication as
specified in TLS 1.3.
</t>
</section>

<section title="Integration with QUIC" anchor="disco-esni-quic" >
<t>
The QUIC Transport uses TLS to negotiate encryption keys. The use of TLS in QUIC is
specified in <xref target="I-D.ietf-quic-tls" />, and can be summarized as follow:
</t>
<t>
<list style="numbers" >
<t>
The QUIC connection starts with the client sending an Initial message, carrying
a TLS ClientHello and its extensions.
</t>
<t>
The server replies with its own Initial message, carrying the server hello and
establishing the "handshake" keys used to protect the reminder of the TLS 1.3
exchange.
</t>
<t>
Server and client exchange encrypted Handshake messages to verify that the
session is properly established and to negotiate the encryption keys of the
application data.
</t>
<t>
Server and Client exchange encrypted application messages until they decide to
close the connection.
</t>
</list>
</t>
<t>
All messages are sent over UDP. 
</t>
<t>
When using Private Discovery, the client adds an ESNI extension to the ClientHello
sent in the Initial message. The ESNI extension is formatted a specified
in <xref target="esni-verif"/>. In classic QUIC, the Initial message would be
sent in a UDP packet to the IP address and UDP port of the server. Instead, the client using
private discovery MUST sent this to the "private discovery" multicast address 
defined in <xref target="iana" /> and to
the UDP port chosen for the application.
</t>
<t>
The multicast message sent by the client will be received by many servers.
The servers using private discovery MUST verify that the ESNI extension is
present. If it is present, each server attempts to decrypt the ESNI extension
using the local private discovery key, as specified in <xref target="esni-verif"/>.
If the verification succeeds, the server proceeds with the connection, and
sends the next QUIC packets to the IP address and UDP port
from which it received the client's first flight.
</t>
<t>
The client receiving the second flight of messages processes them as specified in
DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/>. The client MUST verify that the ESNI
extension is present, and matches the expected value as specified in 
<xref target="esni-verif"/>. If the ESNI extension is absent or does not
pass verification, the entire QUIC connection MUST be ignored. If the verification
succeeds, the client remembers the IP address and UDP port of the server,
and uses it for the reminder of the QUIC connection.
</t>
</section>

</section> 



<section title="Private Discovery DNS Service" >
<t>
The mechanisms discussed in <xref target="esni-design" /> assume that an application
based on DTLS or QUIC is modified to enable private local discovery. This does not
cover all services. Further services can be supported by a two-phase process
in which each application is paired with an implementation of the private
discovery service.
</t> 
<t>
The private discovery service is an implementation of DNS over QUIC, as
specified in <xref target="I-D.huitema-quic-dnsoquic" />, modified to
also implement the Private Discovery over Quic defined in
<xref target="disco-esni-quic" />. The DNS implementation is solely
for the purpose of providing a service equivalent to DNS-SD.
</t>
<t>
The Private Discovery DNS Service is run by the service that wants
to be discovered. The name of the discovery service is the name of the service
that needs to be discovered. Clients are provisioned with the associated
Discovery Key. Clients discover the Private Discovery DNS Service, and can then
use it to obtain the DNS records associated with the application service:
SRV, TXT, A or AAAA records.
</t>


</section> <!-- end of Private Discovery Service -->

<section title="Optional Server Arrival Announce" >
<t>
The proposed design relies on active discovery of servers by the clients. When a client
arrives on a new network and wishes to establish a connection to a server, it sends
a multicast message that tries to reach that server. This designs has two
potential issues:
</t>
<t>
<list>
<t>
If the server is not present when a client tries to contact it, the client may
have to repeat the connection attempts over time.
</t>
<t>
If multiple clients connect to the same server, each client sends a multicast
message, which can translate in heavy multicast load in some configurations.
</t>
</list>
</t>
<t>
The importance of these two issues is debatable. Many applications have a
peer-to-peer nature, in which peers can be either clients or servers. When two
peers are not present at the same time, the first peer to arrive will fail to
establish a connection, but the second peer will succeed, without having to rely
on time based repetitions.
Similarly, if we move from device oriented discovery to application oriented
discovery, the number of client per server is likely to be very small, so
that there will be little difference between "multicast per client" and
"multicast per server".
</t>
<t>
However, there may be configurations where a "server arrival announce" message would
result in fast discovery and fewer multicast messages. 
</t>
<section title="Server Arrival Announce Specification" >
<t>
The server arrival announce message is a UDP packet sent to the Discovery
Multicast Address reserved in <xref target="iana" /> and port %lt;TBD>.
</t>
<t>
The format of the message will be defined in a next draft version, meeting
the following requirements:
</t>
<t>
<list>
<t>
Multiplexing: should be easily demuxed from DTLS or QUIC traffic.
</t>
<t>
ESNI: should contain an ESNI extension, secured with the server's
discovery key.
</t>
<t>
Replay: should contain a timestamp and the global scope IPv6 address
of the server.
</t>
</list>
</t>
</section>

</section>

<section title="Security Considerations">
<t>
The use of TLS 1.3 and the ESNI extension provides robust defenses against attacks.
In particular, Private Discovery benefits from the defenses against
dictionary attacks and replay attacks built in the ESNI design. Protections
against a residual DOS attack is discussed in <xref target="esni-spoof" />.
</t>
<t>
The privacy of the discovery relies on keeping the discovery key of
the service secret. The consequences and partial mitigation of leaking the
discovery key are discussed in <xref target="esni-leak" />.
</t>
<t>
Compromising of the server's private discovery key will allow an
attacker to break the privacy of the discovery, as discussed in <xref target="esni-fail" />.
</t>
<section title="Denial of Service by Spoofed Response" anchor="esni-spoof" >
<t>
Attackers may try to disrupt a private discovery handshake by sending a spoofed
Server Hello (DTLS) or a spoofed Server Initial packet (QUIC). The client will
reject these attempts after noticing that the encrypted extensions do not include
a proper ESNI extension, containing the expected copy of the ESNI nonce.
</t>
<t>
Attackers will not succeed spoofing the server, but they could succeed in denying
the connection if the fake response arrives before the response from the actual
server, and if the implementation just gave up the attempt after failing to validate
the first response that it received.
</t>
<t>
To defend against this attack,
implementations SHOULD keep listening for responses and
attempting validation until they receive at least one valid response from the
expected server.
</t>
</section>
<section title="Discovery Key Compromise" anchor="esni-leak" >
<t>
The Discovery Key is known by all the authorized clients. If one of these clients
is compromised, the privacy of the server will be compromised: attackers
will be able to spoof the authorized client and discover whether the server
is present on a local network. However, the leak can only be exploited in
an active attack: the attacker must actively set up a connection with the
target server. 
</t>
<t>
The attack is mitigated when the server migrates to a different discovery
key and restricts the availability of that key to non-compromised clients.
</t>
<t>
Exploiting a compromised discovery key normally requires that the attacker
is present on the same link as the target. Attackers might try to work
around that limitation by sending unicast packet targeted at plausible
server locations. Servers participating in private discovery MUST NOT
accept discovery requests arriving from off-link sources.
</t>
</section>


<section title="Private Discovery Key Compromise" anchor="esni-fail" >
<t>
The private component of the asymmetric key pair used for discovery MUST
be kept secret by the server. If it is compromised, attackers can
process discovery requests and verify that they can be decrypted with
the server's private discovery key. They could also process logs
of old discovery attempts.
</t>
<t>
The design provides two mitigations against the consequences of this
failure:
</t>
<t>
<list style="symbols" >
<t>
The discovery requests do not uniquely identify the client, and the attacker
will only know that an attempt came from one of the authorized clients.
</t>
<t>
The actual communications are protected by TLS, and inherit the
forward secrecy properties of TLS 1.3.
</t>
</list>
</t>
<t>
[[TODO: consider specifying a way to rotate the discovery key, so as to
mitigate the lack of forward secrecy. Maybe add that to ESNI. ]]
</t>
</section>

<section title="Tracking by Replay" >
<t>
Suppose that an attacker has identified a client, and is capable of
recording the multicast messages from that client. The attacker can
then replay the message, triggering a response from the target server
if present on the network. 
</t>
<t>
The attacker will not be able to actually establish a connection with
the server -- the TSL and ESNI designs protect against that. But it
will be able to find out that the same server that responded to the
client before responds now, which is a way to track the server.
</t>
<t>
The attacker can mount two variations of the attack: replay over time,
and replay at different locations. In the current design, the main
protection against that attack is the implementation of a "discovery
window", so that servers only listen to multicast requests when they
are "ready to be discovered".
</t>
<t>
[[TODO: consider adding a time stamp in an extension to ESNI.]]
</t>
<t>
[[TODO: consider adding the IPv6 address of the sender in an extension to ESNI.]]
</t>
<t>
[[TODO: special consideration for server arrival announce.]]
</t>
</section>

</section> <!-- end of security section -->

<section title="IANA Considerations" anchor="iana">
<t>
IANA is required to allocate the 
IPv6 multicast address FF02::&lt;TBD> for use
as "Private Discovery Multicast Address" described in this document.
</t>

<section title="Experimental use" >
<t>
**RFC Editor's Note:** Please remove this section prior to
 publication of a final version of this document.
</t>
<t>
Early experiments MAY use the address FF02::60DB:F6C5.
This address is marked in the IANA 
registry as unassigned.
</t>
</section>
</section>

<section title="Acknowledgments">
<t>
[[TODO]]
</t>
</section>

</middle>

<back>
<references title="Normative References">
       &rfc2119;
       &rfc6763;
       &rfc8446;
       &I-D.ietf-tls-dtls13;
       &I-D.ietf-tls-esni;
       &I-D.ietf-quic-transport;
       &I-D.ietf-quic-tls;
       &I-D.huitema-quic-dnsoquic;
</references>
<references title="Informative References">
       &rfc6762;
       &I-D.ietf-dnssd-prireq;

<reference anchor="KW14a" target="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7011331">
  <front>
    <title>Adding Privacy to Multicast DNS Service Discovery</title>
    <author initials="D." surname="Kaiser" fullname="Daniel Kaiser">
      <organization/>
    </author>
    <author initials="M." surname="Waldvogel" fullname="Marcel Waldvogel">
      <organization/>
    </author>
    <date year="2014"/>
  </front>
  <seriesInfo name="DOI" value="10.1109/TrustCom.2014.107"/>
</reference>

<reference anchor="KW14b" target="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7056899">
  <front>
    <title>Efficient Privacy Preserving Multicast DNS Service Discovery</title>
    <author initials="D." surname="Kaiser" fullname="Daniel Kaiser">
      <organization/>
    </author>
    <author initials="M." surname="Waldvogel" fullname="Marcel Waldvogel">
      <organization/>
    </author>
    <date year="2014"/>
  </front>
  <seriesInfo name="DOI" value="10.1109/HPCC.2014.141"/>
</reference>

</references>  

</back>
</rfc>