Interoperable Domain Name System (DNS) Server CookiesInternet Systems ConsortiumCZondrej@isc.orgNLnet LabsScience Park 400Amsterdam1098 XHNetherlandswillem@nlnetlabs.nlFuturewei Technologies1424 Pro Shop CourtDavenportFL 33896USA+1-508-333-2270d3e3e3@gmail.comInternet Systems Consortium950 Charter StreetRedwood CityCA 94063USAmarka@isc.org
Internet
DNSOP Working GroupDNS cookies, as specified in RFC 7873, are a lightweight DNS transaction
security mechanism that provides limited protection to DNS servers and
clients against a variety of denial-of-service and amplification, forgery,
or cache poisoning attacks by off-path attackers.
This document provides precise directions for creating Server Cookies so
that an anycast server set including diverse implementations will
interoperate with standard clients.
This document updates DNS cookies, as specified in , are a lightweight DNS transaction
security mechanism that provides limited protection to DNS servers and
clients against a variety of denial-of-service and amplification, forgery,
or cache poisoning attacks by off-path attackers. This document specifies a
means of producing interoperable strong cookies so that an anycast server
set including diverse implementations can be easily configured to
interoperate with standard clients.
The threats considered for DNS Cookies and the properties of the DNS
Security features other than DNS Cookies are discussed in .
In in Section 6 it is "RECOMMENDED for simplicity that
the same Server Secret be used by each DNS server in a set of anycast
servers." However, how precisely a Server Cookie is calculated from
this Server Secret, is left to the implementation.
This guidance has led to a gallimaufry of DNS Cookie implementations,
calculating the Server Cookie in different ways. As a result, DNS Cookies
are impractical to deploy on multi-vendor anycast networks, because even
when all DNS Software share the same secret, as RECOMMENDED in Section
6 of , the Server Cookie constructed by one implementation
cannot generally be validated by another.
There is no need for DNS client (resolver) Cookies to be interoperable
across different implementations. Each client need only be able to recognize
its own cookies. However, this document does contain recommendations for
constructing Client Cookies in a Client protecting fashion.
Section summarises the changes to .
In Section suggestions for constructing a Client
Cookie are given.
In Section instructions for constructing a Server
Cookie are given.
In Section instructions on updating Server Secrets are given.
In Section the different hash functions usable for DNS
Cookie construction are listed. and HMAC-SHA-256-64 are
deprecated and is introduced as a REQUIRED hash function for
server side DNS Cookie implementations.
IANA considerations are in .
Privacy and Security Considerations in .
Acknowledgements are in .
Test vectors are in .
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 when, and only when, they appear in all
capitals, as shown here.
"IP Address" is used herein as a length independent term covering
both IPv4 and IPv6 addresses.In its Appendices A.1 and B.1, provides example "simple" algorithms
for computing Client and Server Cookies, respectively. These algorithms MUST
NOT be used as the resulting cookies are too weak when evaluated against modern
security standards.
In its Appendix B.2, [RFC7873] provides an example "more complex" server
algorithm. This algorithm is replaced by the interoperable specification in
of this document, which MUST be used by Server Cookie
implementations.
This document has suggestions on Client Cookie construction in .
The previous example in Appendix A.2 of is NOT RECOMMENDED.
The Client Cookie is a cryptographic nonce and should be treated as such.
It is RECOMMENDED to create a new Client Cookie for each new upstream server a
Client connects to. The Client Cookie SHOULD have at least 64-bits of entropy.
When a Server does not support DNS Cookies, the Client MUST NOT send the same
Client Cookie to that same Server again. Instead, it is recommended that the
Client does not send a Client Cookie to that Server for a certain period, like
for example five minutes, before it retries with a new Client Cookie.
When a Server does support DNS Cookies, the Client should store the Client
Cookie alongside the Server Cookie it registered for that Server.
Except for when the Client IP address changes, there is no need to change the
Client Cookie often. It is reasonable to change the Client Cookie then only if
it has been compromised or after a relatively long period of time such as no
longer than a year. Client Cookies are not expected to survive a program
restart.
Previously, the recommended algorithm to compute the Client Cookie included
Client IP Address as an input to a hashing function. However, when implementing
the DNS Cookies, several DNS vendors found impractical to include the Client IP
as the Client Cookie is typically computed before the Client IP address is
known. Therefore, the requirement to put Client IP address as input was
removed.
However, for privacy reasons, in order to prevent tracking of devices across
links and to not circumvent IPv6 Privacy Extensions [RFC4941], Clients MUST
NOT re-use a Client or Server Cookie after the Client IP address has changed.
One way to track Client IP addresses, is to register the Client IP address
alongside the Server Cookie when it receives the Server Cookie. In subsequent
queries to the Server with that Server Cookie, the socket MAY be bound to the
Client IP address that was also used (and registered) when it received the
Server Cookie. Failure to bind MUST then result in a new Client Cookie.
The Server Cookie is effectively a Message Authentication Code (MAC) and should
be treated as such. The Server Cookie is calculated from the Client Cookie,
a series of Sub-Fields specified below, the Client IP address, and a Server
Secret known only to the servers responding on the same address in an anycast set.
Changing the Server Secret regularly is RECOMMENDED but, when a secure
pseudorandom function is used, it need not be changed too frequent. For
example once a month would be adequate. See on operator and
implementation guidelines for updating a Server Secret.
The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version Sub-Field,
a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub-Field and an 8 octet Hash
Sub-Field.
The Version Sub-Field prescribes the structure and Hash calculation formula.
This document defines Version 1 to be the structure and way to calculate the
Hash Sub-Field as defined in this Section.
The value of the Reserved Sub-Field is reserved for future versions of Server
Side Cookie construction. On construction it SHOULD be set to zero octets. On
Server Cookie verification the server MUST NOT enforce those fields to be zero
and the Hash should be computed with the received value as described in
.
The Timestamp value prevents Replay Attacks and MUST be checked by the server
to be within a defined period of time. The DNS Server SHOULD allow Cookies
within 1 hour period in the past and 5 minutes into the future to allow
operation of low volume clients and some limited time skew between the DNS
servers in the anycast.
The Timestamp value specifies a date and time in the form of a 32-bit unsigned
number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap
seconds, in network byte order. All comparisons involving these fields MUST
use "Serial number arithmetic", as defined in The DNS Server SHOULD generate a new Server Cookie at least if the received
Server Cookie from the Client is more than half an hour old.
It's important that all the DNS servers use the same algorithm for computing
the Server Cookie. This document defines the Version 1 of the Server Side
algorithm to be:
where "|" indicates concatenation.
Notice that Client-IP is used for hash generation even though it's not included
in the cookie value itself. Client-IP can be either 4 bytes for IPv4 or 16
bytes for IPv6.
The Server Secret MUST be configurable to make sure that servers in an anycast
network return consistent results.
All servers in an anycast group must be able to verify the Server Cookies
constructed by all other servers in that anycast set at all times. Therefore
it is vital that the Server Secret is shared among all servers before it us
used to generate Server Cookies.
Also, to maximize maintaining established relationships between clients and
servers, an old Server Secret should be valid for verification purposes for a
specific period.
To facilitate this, deployment of a new Server Secret MUST be done in three
stages:
The new Server Secret is deployed on all the servers in an anycast set by
the operator.Each server learns the new Server Secret, but keeps using the previous Server
Secret to generate Server Cookies.
Server Cookies constructed with the both the new Server Secret and with
the previous Server Secret are considered valid when verifying.
After stage 1 completed, all the servers in the anycast set have learned the
new Server Secret, and can verify Server Cookies constructed with it, but keep
generating Server Cookies with the old Server Secret.
This stage is initiated by the operator after the Server Cookie is present
on all members in the anycast set.When entering Stage 2, servers start generating Server Cookies with the new
Server Secret. The previous Server Secret is not yet removed/forgotten about.
Server Cookies constructed with the both the new Server Secret and with
the previous Server Secret are considered valid when verifying.
This stage is initiated by the operator when it can be assumed that most
clients have learned the new Server Secret.With this stage, the previous Server Secret can be removed and MUST NOT be
used anymore for verifying.
We RECOMMEND the operator to wait at least a period to be the longest TTL in
the zones served by the server plus half an hour after it initiated Stage 2,
before initiating Stage 3.
The operator SHOULD wait at least longer than the period clients are allowed
to use the same Server Cookie, which SHOULD be half an hour,
see .
is a pseudorandom function suitable as Message Authentication
Code. This document REQUIRES compliant DNS Server to use SipHash-2.4 as a
mandatory and default algorithm for DNS Cookies to ensure interoperability
between the DNS Implementations.
The construction method and pseudorandom function used in calculating and
verifying the Server Cookies are determined by the initial version byte and by
the length of the Server Cookie. Additional pseudorandom or construction
algorithms for Server Cookies might be added in the future.
IANA is requested to create a registry on the "Domain Name System (DNS) Parameters"
IANA web page as follows:
Registry Name: DNS Server Cookie Methods
Assignment Policy: Expert Review
Reference: [this document],
Note: Server Cookie method (construction and pseudorandom algorithm) are
determined by the Version in the first byte of the Cookie and by the Cookie
size. Server Cookie size is limited to the inclusive range of 8 to 32 bytes.
Implementation recommendations for Cookie Algorithms [DNSCOOKIE-IANA]:
VersionSizeMethod08-32reserved18-15unassiged116SipHash-2.4 [this document] 117-32unassigned2-2398-32unassigned240-2548-32private use2558-32reservedDNS Cookies provides limited protection to DNS servers and clients against a
variety of denial-of-service and amplification/forgery or cache poisoning
attacks by off-path attackers. They provide no protection against on-path
adversaries that can observe the plaintext DNS traffic. An on-path adversary
that can observe a Server Cookie for a client and server interaction, can use
that Server Cookie for amplification and denial-of-service forgery attacks
for the lifetime of the Server Cookie.
In it was RECOMMENDED to construct a Client Cookie by using a
pseudorandom function of the Client IP Address, the Server IP Address, and a
secret quantity known only to the client. The Client IP Address was included to
ensure that a client could not be tracked if its IP Address changes due to
privacy mechanisms or otherwise.
In this document, we changed Client Cookie construction to be just 64 bits of
entropy newly created for each new upstream server the client connects to.
As a consequence additional care needs to be taken to prevent tracking of
clients. To prevent tracking, a new Client Cookie for a server MUST be created
whenever the Client IP Address changes.
Unfortunately, tracking Client IP Address Changes is impractical with servers
that do not support DNS Cookies. To prevent tracking of clients with non DNS
Cookie supporting servers, a client MUST NOT send a previously sent Client
Cookie. To prevent the creation of a new Client Cookie for each query to an non
DNS Cookies supporting server, it is RECOMMENDED to not send a Client Cookie to
that server for a certain period, like for example five minute.
Summarizing:
In order to provide minimal authentication, a client MUST use a
different Client Cookie for each different Server IP Address.To prevent tracking of clients, a new Client Cookie MUST be created
when the Client IP Address changes.To prevent tracking of clients for a non DNS Cookie supporting server,
a client MUST NOT send a previously sent Client Cookie to that server,
unless it can track Client IP Address changes for those servers too.Besides the Client Cookie construction, this update on does not
introduce any new characteristics to DNS Cookies operations and the Security
Considerations section of still applies.
SipHash: a fast short-input PRFThe FNV Non-Cryptographic Hash AlgorithmThanks to Witold Krecicki and Pieter Lexis for valuable input, suggestions and
text and above all for implementing a prototype of an interoperable DNS Cookie
in Bind9, Knot and PowerDNS during the hackathon of IETF104 in Prague. Thanks
for valuable input and suggestions go to Ralph Dolmans, Bob Harold, Daniel
Salzman, Martin Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron,
Bob Harold and Philip Homburg
A resolver (client) sending from IPv4 address 198.51.100.100, sends a query for
example.com to an authoritative server listening on 192.0.2.53 from
which it has not yet learned the server cookie.
The DNS requests and replies shown in this Appendix, are in a "dig" like format.
The content of the DNS COOKIE Option is shown in hexadecimal format after
; COOKIE:.
The authoritative nameserver (server) is configured with the following secret:
e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data).
It receives the query at Wed Jun 5 10:53:05 UTC 2019.
The content of the DNS COOKIE Option that the server will return is shown
below in hexadecimal format after ; COOKIE:40 minutes later, the same resolver (client) queries the same server for
for example.org :
The authoritative nameserver (server) now generates a new Server Cookie.
The server SHOULD do this because it can see the Server Cookie send by the
client is older than half an hour , but it is also fine for
a server to generate a new Server Cookie sooner, or even for every answer.
Another resolver (client) with IPv4 address 203.0.113.203 sends a request to
the same server with a valid Server Cookie that it learned before
(at Wed Jun 5 09:46:25 UTC 2019). Note that the Server Cookie has Reserved bytes set,
but is still valid with the configured secret; the Hash part is calculated
taking along the Reserved bytes.
The authoritative nameserver (server) replies with a freshly generated Server
Cookie for this client conformant with this specification; so with the Reserved
bits set to zero.
The query below is from a client with IPv6 address 2001:db8:220:1:59de:d0f4:8769:82b8 to a server
with IPv6 address 2001:db8:8f::53. The client has learned a valid Server Cookie
before when the Server had secret: dd3bdf9344b678b185a6f5cb60fca715. The server now uses a
new secret, but it can still validate the Server Cookie provided by the client
as the old secret has not expired yet.
The authoritative nameserver (server) replies with a freshly generated server
cookie for this client with its new secret: 445536bcd2513298075a5d379663c962