< draft-ietf-dnsop-cookies-07.txt   draft-ietf-dnsop-cookies-10.txt >
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended Status: Proposed Standard Huawei Intended Status: Proposed Standard Huawei
Mark Andrews Mark Andrews
ISC ISC
Expires: May 1, 2016 November 2, 2015 Expires: October 4, 2016 April 5, 2016
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-07.txt> <draft-ietf-dnsop-cookies-10.txt>
Abstract Abstract
DNS cookies are a lightweight DNS transaction security mechanism that DNS cookies are a lightweight DNS transaction security mechanism that
provides limited protection to DNS servers and clients against a provides limited protection to DNS servers and clients against a
variety of increasingly common denial-of-service and amplification / variety of increasingly common denial-of-service and amplification /
forgery or cache poisoning attacks by off-path attackers. DNS Cookies forgery or cache poisoning attacks by off-path attackers. DNS Cookies
are tolerant of NAT, NAT-PT, and anycast and can be incrementally are tolerant of NAT, NAT-PT, and anycast and can be incrementally
deployed. deployed. (Since DNS Cookies are only returned to the IP address from
which they were originally received, they cannot be used to generally
track Internet users.)
Status of This Document Status of This Document
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the author or the DNSEXT mailing list <dnsext@ietf.org>. to the author or the DNSEXT mailing list <dnsext@ietf.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4.2 Server Cookie.........................................11 4.2 Server Cookie.........................................11
5. DNS Cookies Protocol Specification.....................12 5. DNS Cookies Protocol Specification.....................12
5.1 Originating Requests..................................12 5.1 Originating Requests..................................12
5.2 Responding to Request.................................12 5.2 Responding to Request.................................12
5.2.1 No Opt RR or No COOKIE OPT option...................13 5.2.1 No Opt RR or No COOKIE OPT option...................13
5.2.2 Malformed COOKIE OPT option.........................13 5.2.2 Malformed COOKIE OPT option.........................13
5.2.3 Only a Client Cookie................................13 5.2.3 Only a Client Cookie................................13
5.2.4 A Client Cookie and an Invalid Server Cookie........14 5.2.4 A Client Cookie and an Invalid Server Cookie........14
5.2.5 A Client Cookie and a Valid Server Cookie...........14 5.2.5 A Client Cookie and a Valid Server Cookie...........14
5.3 Processing Responses..................................14 5.3 Processing Responses..................................15
5.4 QUERYing for a Server Cookie..........................15 5.4 QUERYing for a Server Cookie..........................15
5.5 Client and Server Secret Rollover.....................16
6. NAT Considerations and AnyCast Server Considerations...17 6. NAT Considerations and AnyCast Server Considerations...17
7. Deployment.............................................19
8. IANA Considerations....................................20
9. Security Considerations................................21 7. Operational and Deployment Considerations..............19
9.1 Cookie Algorithm Considerations.......................21 7.1 Client and Server Secret Rollover.....................19
7.2 Counters..............................................20
10. Implementation Considerations.........................23 8. IANA Considerations....................................21
Normative References......................................24 9. Security Considerations................................22
Informative References....................................24 9.1 Cookie Algorithm Considerations.......................23
Acknowledgements..........................................26
Appendix A: Example Client Cookie Algorithms..............27 10. Implementation Considerations.........................24
A.1 A Simple Algorithm....................................27
A.2 A More Complex Algorithm..............................27 Normative References......................................25
Informative References....................................25
Acknowledgements..........................................27
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Table of Contents (continued) Table of Contents (continued)
Appendix B: Example Server Cookie Algorithms..............28 Appendix A: Example Client Cookie Algorithms..............28
B.1 A Simple Algorithm....................................28 A.1 A Simple Algorithm....................................28
B.2 A More Complex Algorithm..............................28 A.2 A More Complex Algorithm..............................28
Author's Address..........................................30 Appendix B: Example Server Cookie Algorithms..............29
B.1 A Simple Algorithm....................................29
B.2 A More Complex Algorithm..............................29
Author's Address..........................................31
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
1. Introduction 1. Introduction
As with many core Internet protocols, the Domain Name System (DNS) As with many core Internet protocols, the Domain Name System (DNS)
was originally designed at a time when the Internet had only a small was originally designed at a time when the Internet had only a small
pool of trusted users. As the Internet has grown exponentially to a pool of trusted users. As the Internet has grown exponentially to a
global information utility, the DNS has increasingly been subject to global information utility, the DNS has increasingly been subject to
abuse. abuse.
This document describes DNS cookies, a lightweight DNS transaction This document describes DNS cookies, a lightweight DNS transaction
security mechanism specified as an OPT [RFC6891] option. The DNS security mechanism specified as an OPT [RFC6891] option. The DNS
cookies mechanism provides limited protection to DNS servers and cookies mechanism provides limited protection to DNS servers and
clients against a variety of increasingly common abuses by off-path clients against a variety of increasingly common abuses by off-path
attackers. It is compatible with and can be used in conjunction with attackers. It is compatible with and can be used in conjunction with
other DNS transaction forgery resistance measures such as those in other DNS transaction forgery resistance measures such as those in
[RFC5452]. [RFC5452]. (Since DNS Cookies are only returned to the IP address
from which they were originally received, they cannot be used to
generally track Internet users.)
The protection provided by DNS cookies is similar to that provided by The protection provided by DNS cookies is similar to that provided by
using TCP for DNS transactions. To bypass the weak protection using TCP for DNS transactions. To bypass the weak protection
provided by using TCP requires, among other things, that an off-path provided by using TCP requires, among other things, that an off-path
attacker guessing the 32-bit TCP sequence number in use. To bypass attacker guess the 32-bit TCP sequence number in use. To bypass the
the weak protection provided by DNS Cookies requires such an attacker weak protection provided by DNS Cookies requires such an attacker to
to guess a 64-bit pseudo-random "cookie" quantity. Where DNS Cookies guess a 64-bit pseudo-random "cookie" quantity. Where DNS Cookies are
are not available but TCP is, falling back to using TCP is not available but TCP is, falling back to using TCP is reasonable.
reasonable.
If only one party to a DNS transaction supports DNS cookies, the If only one party to a DNS transaction supports DNS cookies, the
mechanism does not provide a benefit or significantly interfere; but, mechanism does not provide a benefit or significantly interfere; but,
if both support it, the additional security provided is automatically if both support it, the additional security provided is automatically
available. available.
The DNS cookies mechanism is designed to work in the presence of NAT The DNS cookies mechanism is designed to work in the presence of NAT
and NAT-PT boxes and guidance is provided herein on supporting the and NAT-PT boxes and guidance is provided herein on supporting the
DNS cookies mechanism in anycast servers. DNS cookies mechanism in anycast servers.
skipping to change at page 4, line 54 skipping to change at page 5, line 4
mechanism provides some protection. mechanism provides some protection.
Section 3 describes existing DNS security mechanisms and why they are Section 3 describes existing DNS security mechanisms and why they are
not adequate substitutes for DNS cookies. not adequate substitutes for DNS cookies.
Section 4 describes the COOKIE OPT option. Section 4 describes the COOKIE OPT option.
Section 5 provides a protocol description. Section 5 provides a protocol description.
Section 6 discusses some NAT and anycast related DNS Cookies design Section 6 discusses some NAT and anycast related DNS Cookies design
considerations.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
considerations.
Section 7 discusses incremental deployment considerations. Section 7 discusses incremental deployment considerations.
Sections 8 and 9 describe IANA and Security Considerations. Sections 8 and 9 describe IANA and Security Considerations.
1.2 Definitions 1.2 Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
"Off-path attacker", for a particular DNS client and server, is "Off-path attacker", for a particular DNS client and server, is
defined as an attacker who cannot observe the DNS request and defined as an attacker who cannot observe the DNS request and
response messages between that client and server. response messages between that client and server.
"Soft state" indicates information learned or derived by a host which "Soft state" indicates information learned or derived by a host which
may be discarded when indicated by the policies of that host may be discarded when indicated by the policies of that host
but can be later re-instantiated if needed. For example, it but can be later re-instantiated if needed. For example, it
could be discarded after a period of time or when storage for could be discarded after a period of time or when storage for
caching such data becomes full. If operations requiring that caching such data becomes full. If operations requiring that
soft state continue after it has been discarded, it will be soft state continue after it has been discarded, it will be
automatically re-generated, albeit at some cost. automatically re-generated, albeit at some cost.
"Silently discarded" indicates that there are no DNS protocol message "Silently discarded" indicates that there are no DNS protocol message
consequences; however, it is RECOMMENDED that appropriate consequences.
network management facilities be included in implementations,
such as a counter of the occurrences of each such event type.
"IP address" is used herein as a length independent term and includes "IP address" is used herein as a length independent term and includes
both IPv4 and IPv6 addresses. both IPv4 and IPv6 addresses.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
2. Threats Considered 2. Threats Considered
DNS cookies are intended to provide significant but limited DNS cookies are intended to provide significant but limited
protection against certain attacks by off-path attackers as described protection against certain attacks by off-path attackers as described
skipping to change at page 8, line 28 skipping to change at page 8, line 28
forged data and cache poisoning; however, it has the unintended forged data and cache poisoning; however, it has the unintended
effect of making some denial-of-service attacks worse because of the effect of making some denial-of-service attacks worse because of the
cryptographic computational load it can require and the increased cryptographic computational load it can require and the increased
size in DNS response packets that it tends to produce. size in DNS response packets that it tends to produce.
3.2 DNS Message/Transaction Security 3.2 DNS Message/Transaction Security
The second form of security that has been added to DNS provides The second form of security that has been added to DNS provides
"transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931]. "transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931].
TSIG could provide strong protection against the attacks for which TSIG could provide strong protection against the attacks for which
the DNS Cookies mechanism provides weak protection; however, TSIG is the DNS Cookies mechanism provides weaker protection; however, TSIG
non-trivial to deploy in the general Internet because of the burdens is non-trivial to deploy in the general Internet because of the
it imposes. Among these burdens are pre-agreement and key burdens it imposes. Among these burdens are pre-agreement and key
distribution between client and server, keeping track of server side distribution between client and server, keeping track of server side
key state, and required time synchronization between client and key state, and required time synchronization between client and
server. server.
TKEY [RFC2930] can solve the problem of key distribution for TSIG but TKEY [RFC2930] can solve the problem of key distribution for TSIG but
some modes of TKEY impose a substantial cryptographic computation some modes of TKEY impose a substantial cryptographic computation
load and can be dependent on the deployment of DNS data security (see load and can be dependent on the deployment of DNS data security (see
Section 3.1). Section 3.1).
SIG(0) [RFC2931] provides less denial of service protection than TSIG SIG(0) [RFC2931] provides less denial of service protection than TSIG
skipping to change at page 11, line 9 skipping to change at page 11, line 9
/ Server Cookie (variable size, 8 to 32 bytes) / / Server Cookie (variable size, 8 to 32 bytes) /
/ / / /
+-+-+-+-... +-+-+-+-...
Figure 2. COOKIE Option, Known Server Cookie Figure 2. COOKIE Option, Known Server Cookie
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
4.1 Client Cookie 4.1 Client Cookie
The Client Cookie SHOULD be a pseudo-random function of the server IP The Client Cookie SHOULD be a pseudo-random function of the client IP
address and a secret quantity known only to the client. This client address, the server IP address, and a secret quantity known only to
secret SHOULD have at least 64 bits of entropy [RFC4086] and be the client. This client secret SHOULD have at least 64 bits of
changed periodically (see Section 5.5). The selection of the pseudo- entropy [RFC4086] and be changed periodically (see Section 7.1). The
random function is a matter private to the client as only the client selection of the pseudo-random function is a matter private to the
needs to recognize its own DNS cookies. client as only the client needs to recognize its own DNS cookies.
The client IP address is included so that the Client Cookie cannot be
used (1) to track a client if the client IP address changes due to
privacy mechanisms or (2) to impersonate the client by some network
device that was formerly on path but is no longer on path when the
client IP address changes due to mobility. However, if the client IP
address is being changed very often, it may be necessary to fix the
Client Cookie for a particular server for several requests to avoid
undue inefficiency due to retries caused by that server not
recognizing the Client Cookie.
For further discussion of the Client Cookie field, see Section 5.1. For further discussion of the Client Cookie field, see Section 5.1.
For example methods of determining a Client Cookie, see Appendix A. For example methods of determining a Client Cookie, see Appendix A.
In order to provide minimal authentication, a client MUST send Client In order to provide minimal authentication, a client MUST send Client
Cookies that will usually be different for any two servers at Cookies that will usually be different for any two servers at
different IP addresses. different IP addresses.
4.2 Server Cookie 4.2 Server Cookie
The Server Cookie SHOULD consist of or include a 64-bit or larger The Server Cookie SHOULD consist of or include a 64-bit or larger
pseudo-random function of the request source IP address, the request pseudo-random function of the request source (client) IP address, a
Client Cookie, and a secret quantity known only to the server. (See secret quantity known only to the server, and the request Client
Section 6 for a discussion of why the Client Cookie is used as input Cookie. (See Section 6 for a discussion of why the Client Cookie is
to the Server Cookie but the Server Cookie is not used as an input to used as input to the Server Cookie but the Server Cookie is not used
the Client Cookie.) This server secret SHOULD have at least 64 bits as an input to the Client Cookie.) This server secret SHOULD have at
of entropy [RFC4086] and be changed periodically (see Section 5.5). least 64 bits of entropy [RFC4086] and be changed periodically (see
The selection of the pseudo-random function is a matter private to Section 7.1). The selection of the pseudo-random function is a
the server as only the server needs to recognize its own DNS cookies. matter private to the server as only the server needs to recognize
its own DNS cookies.
For further discussion of the Server Cookie field see Section 5.2. For further discussion of the Server Cookie field see Section 5.2.
For example methods of determining a Server Cookie, see Appendix B. For example methods of determining a Server Cookie, see Appendix B.
When implemented as recommended, the server need not maintain any
cookie related per client state.
In order to provide minimal authentication, a server MUST send Server In order to provide minimal authentication, a server MUST send Server
Cookies that will usually be different for clients at any two Cookies that will usually be different for clients at any two
different IP addresses or with different Client Cookies. different IP addresses or with different Client Cookies.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
5. DNS Cookies Protocol Specification 5. DNS Cookies Protocol Specification
This section discusses using DNS Cookies in the DNS Protocol. The This section discusses using DNS Cookies in the DNS Protocol. The
cycle of originating a request, responding to that request, and cycle of originating a request, responding to that request, and
processing the response are covered in Sections 5.1, 5.2, and 5.3. A processing the response are covered in Sections 5.1, 5.2, and 5.3. A
de facto extension to QUERY to allow pre-fetching a Server Cookie is de facto extension to QUERY to allow pre-fetching a Server Cookie is
specified in Section 5.4. Rollover of the client and server secrets specified in Section 5.4. Rollover of the client and server secrets
and transient retention of the old cookie or secret is covered in and transient retention of the old cookie or secret is covered in
Section 5.5. Section 7.1.
DNS clients and servers SHOULD implement DNS cookies to decrease DNS clients and servers SHOULD implement DNS cookies to decrease
their vulnerability to the threats discussed in Section 2. their vulnerability to the threats discussed in Section 2.
5.1 Originating Requests 5.1 Originating Requests
A DNS client that implements DNS Cookies includes one DNS COOKIE OPT A DNS client that implements DNS Cookies includes one DNS COOKIE OPT
option containing a Client Cookie in every DNS request it sends option containing a Client Cookie in every DNS request it sends
unless DNS cookies are disabled. unless DNS cookies are disabled.
skipping to change at page 12, line 37 skipping to change at page 12, line 37
IP address it uses the longer cookie form and includes that Server IP address it uses the longer cookie form and includes that Server
Cookie in the option along with the Client Cookie (Figure 2). Cookie in the option along with the Client Cookie (Figure 2).
Otherwise it just sends the shorter form option with a Client Cookie Otherwise it just sends the shorter form option with a Client Cookie
(Figure 1). (Figure 1).
5.2 Responding to Request 5.2 Responding to Request
The Server Cookie, when it occurs in a COOKIE OPT option in a The Server Cookie, when it occurs in a COOKIE OPT option in a
request, is intended to weakly assure the server that the request request, is intended to weakly assure the server that the request
came from a client that is both at the source IP address of the came from a client that is both at the source IP address of the
request and using the Client Cookie included in the option. This weak request and using the Client Cookie included in the option. This
assurance is provided by the Server Cookie that server sent to that assurance is provided by the Server Cookie that server sent to that
client in an earlier response appearing as the Server Cookie field in client in an earlier response appearing as the Server Cookie field in
the request. the request.
At a server where DNS Cookies are not implemented and enabled, At a server where DNS Cookies are not implemented and enabled,
presence of a COOKIE OPT option is ignored and the server responds as presence of a COOKIE OPT option is ignored and the server responds as
if no COOKIE OPT option had been included in the request. if no COOKIE OPT option had been included in the request.
When DNS Cookies are implemented and enabled, there are five When DNS Cookies are implemented and enabled, there are five
possibilities: (1) there is no OPT RR at all in the request or there possibilities: (1) there is no OPT RR at all in the request or there
is a OPT RR but the the COOKIE OPT option is absent from the OPT RR; is a OPT RR but the COOKIE OPT option is absent from the OPT RR; (2)
(2) a COOKIE OPT is present but is not a legal length or otherwise a COOKIE OPT is present but is not a legal length or otherwise
malformed; (3) there is a valid length cookie option in the request malformed; (3) there is a valid length cookie option in the request
with no Server Cookie; (4) there is a valid length COOKIE OPT in the with no Server Cookie; (4) there is a valid length COOKIE OPT in the
request with a Server Cookie but that Server Cookie is invalid; or request with a Server Cookie but that Server Cookie is invalid; or
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
(5) there is a valid length COOKIE OPT in the request with a correct (5) there is a valid length COOKIE OPT in the request with a correct
Server Cookie. Server Cookie.
The five possibilities are discussed in the subsections below. The five possibilities are discussed in the subsections below.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
5.2.1 No Opt RR or No COOKIE OPT option 5.2.1 No Opt RR or No COOKIE OPT option
If there is no OPT record or no COOKIE OPT option present in the If there is no OPT record or no COOKIE OPT option present in the
request then the server responds to the request as if the server request then the server responds to the request as if the server
doesn't implement the COOKIE OPT. doesn't implement the COOKIE OPT.
5.2.2 Malformed COOKIE OPT option 5.2.2 Malformed COOKIE OPT option
If the COOKIE OPT is too short to contain a Client Cookie then If the COOKIE OPT is too short to contain a Client Cookie then
FORMERR is generated. If the COOKIE OPT is longer than that required FORMERR is generated. If the COOKIE OPT is longer than that required
to hold a COOKIE OPT with just a Client Cookie (8) but is shorter to hold a COOKIE OPT with just a Client Cookie (8 bytes) but is
that the minimum COOKIE OPT with both a Client and Server Cookie (16) shorter that the minimum COOKIE OPT with both a Client and Server
then FORMERR is generated. If the COOKIE OPT is longer than the Cookie (16 bytes) then FORMERR is generated. If the COOKIE OPT is
maximum valid COOKIE OPT (40) then a FORMERR is generated. longer than the maximum valid COOKIE OPT (40 bytes) then a FORMERR is
generated.
In summary, valid cookie lengths are 8 and 16 to 40 inclusive. In summary, valid cookie lengths are 8 and 16 to 40 inclusive.
5.2.3 Only a Client Cookie 5.2.3 Only a Client Cookie
Based on server policy, including rate limiting, the server chooses Based on server policy, including rate limiting, the server chooses
one of the following: one of the following:
(1) Silently discard the request. (1) Silently discard the request.
(2) Send a BADCOOKIE error response. (2) Send a BADCOOKIE error response.
(3) Process the request and provide a normal response. The RCODE is (3) Process the request and provide a normal response. The RCODE is
NOERROR unless some non-cookie error occurs in processing the NOERROR unless some non-cookie error occurs in processing the
request. request.
If the server responds, choosing 2 or 3 above, it SHALL generate its If the server responds, choosing 2 or 3 above, it SHALL generate its
own COOKIE OPT containing both the Client Cookie copied from the own COOKIE OPT containing both the Client Cookie copied from the
request and a Server Cookie it has generated and adds this COOKIE OPT request and a Server Cookie it has generated and adds this COOKIE OPT
to the response's OPT record. Servers MUST, at least occasionally, to the response's OPT record. Servers MUST, at least occasionally,
respond to such requests to inform the client of the correct Server
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
respond to such requests to inform the client of the correct Server
Cookie. This is necessary so that such a client can bootstrap to the Cookie. This is necessary so that such a client can bootstrap to the
weakly secure state where requests and responses have recognized more secure state where requests and responses have recognized Server
Server Cookies and Client Cookies. A server is not expected to Cookies and Client Cookies. A server is not expected to maintain per
maintain per client state to achieve this. For example, it could client state to achieve this. For example, it could respond to every
respond to every Nth request across all clients. Nth request across all clients.
If the request was received over TCP, the server SHOULD take the weak If the request was received over TCP, the server SHOULD take the
authentication provided by the use of TCP into account and SHOULD authentication provided by the use of TCP into account and SHOULD
choose 3. In this case, if the server is not willing to accept the choose 3. In this case, if the server is not willing to accept the
weak security provided by TCP as a substitute for the weak security security provided by TCP as a substitute for the security provided by
provided by DNS Cookies but instead chooses 2, there is some danger DNS Cookies but instead chooses 2, there is some danger of an
of an indefinite loop of retries (see Section 5.3). indefinite loop of retries (see Section 5.3).
5.2.4 A Client Cookie and an Invalid Server Cookie 5.2.4 A Client Cookie and an Invalid Server Cookie
The server examines the Server Cookie to determine if it is a valid The server examines the Server Cookie to determine if it is a valid
Server Cookie it has generated. This examination will result in a Server Cookie it has generated. This determination normally involves
determination of whether the Server Cookie is valid or not. If the re-calculating the Server Cookie (or the hash part thereof) based on
the server secret (or the previous server secret if it has just
changed), the received Client Cookie, the client IP address, and
possibly other fields -- see Appendix B.2 for an example. If the
cookie is invalid, it can be because of a stale Server Cookie, or a cookie is invalid, it can be because of a stale Server Cookie, or a
client's IP address or Client Cookie changing without the DNS server client's IP address or Client Cookie changing without the DNS server
being aware, or an anycast server cluster that is not consistently being aware, or an anycast server cluster that is not consistently
configured, or an attempt to spoof the client. configured, or an attempt to spoof the client.
The server SHALL process the request as if the invalid Server Cookie The server SHALL process the request as if the invalid Server Cookie
was not present as described in Section 5.2.3. was not present as described in Section 5.2.3.
5.2.5 A Client Cookie and a Valid Server Cookie 5.2.5 A Client Cookie and a Valid Server Cookie
When a valid Server Cookie is present in the request the server can When a valid Server Cookie is present in the request the server can
assume that the request is from a client that it has talked to before assume that the request is from a client that it has talked to before
and defensive measures for spoofed UDP requests, if any, are no and defensive measures for spoofed UDP requests, if any, are no
longer required. longer required.
The server SHALL process the request and include a COOKIE OPT in the The server SHALL process the request and include a COOKIE OPT in the
response by (a) copying the complete COOKIE OPT from the request or response by (a) copying the complete COOKIE OPT from the request or
(b) generating a new COOKIE OPT containing both the Client Cookie (b) generating a new COOKIE OPT containing both the Client Cookie
copied from the request and a valid Server Cookie it has generated. copied from the request and a valid Server Cookie it has generated.
INTERNET-DRAFT DNS Cookies
5.3 Processing Responses 5.3 Processing Responses
The Client Cookie, when it occurs in a COOKIE OPT option in a DNS The Client Cookie, when it occurs in a COOKIE OPT option in a DNS
reply, is intended to weakly assure the client that the reply came reply, is intended to weakly assure the client that the reply came
from a server at the source IP address used in the response packet from a server at the source IP address used in the response packet
because the Client Cookie value is the value that client would send because the Client Cookie value is the value that client would send
INTERNET-DRAFT DNS Cookies
to that server in a request. In a DNS reply with multiple COOKIE OPT to that server in a request. In a DNS reply with multiple COOKIE OPT
options, all but the first (the one closest to the DNS Header) are options, all but the first (the one closest to the DNS Header) are
ignored. ignored.
A DNS client where DNS cookies are implemented and enabled examines A DNS client where DNS cookies are implemented and enabled examines
the response for DNS cookies and MUST discard the response if it the response for DNS cookies and MUST discard the response if it
contains an illegal COOKIE OPT option length or an incorrect Client contains an illegal COOKIE OPT option length or an incorrect Client
Cookie value. If the COOKIE OPT option Client Cookie is correct, the Cookie value. If the client is expecting the response to contain a
client caches the Server Cookie provided even if the response is an COOKIE OPT and it is missing the response MUST be discarded. If the
error response (RCODE non-zero). COOKIE OPT option Client Cookie is correct, the client caches the
Server Cookie provided even if the response is an error response
(RCODE non-zero).
If the reply extended RCODE is BADCOOKIE and the Client Cookie If the reply extended RCODE is BADCOOKIE and the Client Cookie
matches what was sent, it means that the server was unwilling to matches what was sent, it means that the server was unwilling to
process the request because it did not have the correct Server Cookie process the request because it did not have the correct Server Cookie
in it. The client SHOULD retry the request using the new Server in it. The client SHOULD retry the request using the new Server
Cookie from the response. Repeated BADCOOKIE responses to requests Cookie from the response. Repeated BADCOOKIE responses to requests
that use the Server Cookie provided in the previous response may be that use the Server Cookie provided in the previous response may be
an indication that the shared secrets / secret generation method in an indication that the shared secrets / secret generation method in
an anycast cluster of servers are inconsistent. If the reply to a an anycast cluster of servers are inconsistent. If the reply to a
retried request with a fresh Server Cookie is BADCOOKIE, the client retried request with a fresh Server Cookie is BADCOOKIE, the client
SHOULD retry using TCP as the transport since the server will likely SHOULD retry using TCP as the transport since the server will likely
process the request normally based on the weak security provided by process the request normally based on the security provided by TCP
TCP (see Section 5.2.3). (see Section 5.2.3).
If the RCODE is some value other than BADCOOKIE, including zero, the If the RCODE is some value other than BADCOOKIE, including zero, the
further processing of the response proceeds normally. further processing of the response proceeds normally.
5.4 QUERYing for a Server Cookie 5.4 QUERYing for a Server Cookie
In many cases a client will learn the Server Cookie for a server as In many cases a client will learn the Server Cookie for a server as
the side effect of another transaction; however, there may be times the side effect of another transaction; however, there may be times
when this is not desirable. Therefore a means is provided for when this is not desirable. Therefore a means is provided for
obtaining a Server Cookie through an extension to the QUERY opcode obtaining a Server Cookie through an extension to the QUERY opcode
for which opcode most existing implementations require that QDCOUNT for which opcode most existing implementations require that QDCOUNT
be one (see Section 4.1.2 of [RFC1035]). be one (see Section 4.1.2 of [RFC1035]).
For servers with DNS Cookies enabled, the QUERY opcode behavior is For servers with DNS Cookies enabled, the QUERY opcode behavior is
extended to support queries with a empty question section (QDCOUNT extended to support queries with an empty question section (QDCOUNT
zero) provided that an OPT record is present with a COOKIE option. zero) provided that an OPT record is present with a COOKIE option.
Such servers will reply with an empty answer section and a COOKIE Such servers will reply with an empty answer section and a COOKIE
INTERNET-DRAFT DNS Cookies
option giving the Client Cookie provided in the query and a valid option giving the Client Cookie provided in the query and a valid
Server Cookie. Server Cookie.
If such a query provided just a Client Cookie and no Server Cookie, If such a query provided just a Client Cookie and no Server Cookie,
the response SHALL have the RCODE NOERROR. the response SHALL have the RCODE NOERROR.
This mechanism can also be used to confirm/re-establish a existing This mechanism can also be used to confirm/re-establish an existing
Server Cookie by sending a cached Server Cookie with the Client Server Cookie by sending a cached Server Cookie with the Client
INTERNET-DRAFT DNS Cookies
Cookie. In this case the response SHALL have the RCODE BADCOOKIE if Cookie. In this case the response SHALL have the RCODE BADCOOKIE if
the Server Cookie sent with the query was invalid and the RCODE the Server Cookie sent with the query was invalid and the RCODE
NOERROR if it was valid. NOERROR if it was valid.
Servers which don't support the COOKIE option will normally send Servers which don't support the COOKIE option will normally send
FORMERR in response to such a query, though REFUSED, NOTIMP, and FORMERR in response to such a query, though REFUSED, NOTIMP, and
NOERROR without a COOKIE option are also possible in such responses. NOERROR without a COOKIE option are also possible in such responses.
5.5 Client and Server Secret Rollover
The longer a secret is used, the higher the probability it has been
compromised. Thus clients and servers MUST NOT continue to use the
same secret in new requests and responses for more than 36 days and
SHOULD NOT continue to do so for more than 26 hours. These values are
chosen to assure that a secret will not be used for longer than about
a month and normally no longer than one day. The odd values are to
allow for long holiday weekends and daylight savings time shifts and
the like while still staying within the limits.
Many clients rolling over their secret at the same time could briefly
increase server traffic and exactly predictable rollover times for
clients or servers might facilitate guessing attacks. For example, an
attacker might increase the priority of attacking secrets they
believe will be in effect for an extended period of time. To avoid
rollover synchronization and predictability, it is RECOMMENDED that
pseudorandom jitter in the range of plus zero to minus at least 40%
be applied to the time until a scheduled rollover of a DNS cookie
secret.
It is RECOMMENDED that a client keep the Client Cookie it is
expecting in a reply associated with the outstanding request to avoid
rejection of replies due to a bad Client Cookie right after a change
in the client secret. It is RECOMMENDED that a server retain its
previous secret for a period of time not less than 1 second or more
than 5 minutes, after a change in its secret, and consider requests
with Server Cookies based on its previous secret to have a correct
Server Cookie during that time.
When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack
and it should consider a more frequent rollover of its secret. More
rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
6. NAT Considerations and AnyCast Server Considerations 6. NAT Considerations and AnyCast Server Considerations
In the Classic Internet, DNS Cookies could simply be a pseudo-random In the Classic Internet, DNS Cookies could simply be a pseudo-random
function of the client IP address and a server secret or the server function of the client IP address and a server secret or the server
IP address and a client secret. You would want to compute the Server IP address and a client secret. You would want to compute the Server
Cookie that way, so a client could cache its Server Cookie for a Cookie that way, so a client could cache its Server Cookie for a
particular server for an indefinitely amount of time and the server particular server for an indefinite amount of time and the server
could easily regenerate and check it. You could consider the Client could easily regenerate and check it. You could consider the Client
Cookie to be a weak client signature over the server IP address that Cookie to be a weak client signature over the server IP address that
the client checks in replies and you could extend this weak signature the client checks in replies and you could extend this signature to
to cover the request ID, for example, or any other information that cover the request ID, for example, or any other information that is
is returned unchanged in the reply. returned unchanged in the reply.
But we have this reality called NAT [RFC3022], Network Address But we have this reality called NAT [RFC3022], Network Address
Translation (including, for the purposes of this document, NAT-PT, Translation (including, for the purposes of this document, NAT-PT,
Network Address and Protocol Translation, which has been declared Network Address and Protocol Translation, which has been declared
Historic [RFC4966]). There is no problem with DNS transactions Historic [RFC4966]). There is no problem with DNS transactions
between clients and servers behind a NAT box using local IP between clients and servers behind a NAT box using local IP
addresses. Nor is there a problem with NAT translation of internal addresses. Nor is there a problem with NAT translation of internal
addresses to external addresses or translations between IPv4 and IPv6 addresses to external addresses or translations between IPv4 and IPv6
addresses, as long as the address mapping is relatively stable. addresses, as long as the address mapping is relatively stable.
Should the external IP address an internal client is being mapped to Should the external IP address an internal client is being mapped to
skipping to change at page 18, line 42 skipping to change at page 18, line 42
are not unduly burdensome. (When such anycast-accessed servers act are not unduly burdensome. (When such anycast-accessed servers act
as recursive servers or otherwise act as clients they normally use a as recursive servers or otherwise act as clients they normally use a
different unique address to source their requests to avoid confusion different unique address to source their requests to avoid confusion
in the delivery of responses.) in the delivery of responses.)
For simplicity, it is RECOMMENDED that the same server secret be used For simplicity, it is RECOMMENDED that the same server secret be used
by each DNS server in a set of anycast servers. If there is limited by each DNS server in a set of anycast servers. If there is limited
time skew in updating this secret in different anycast servers, this time skew in updating this secret in different anycast servers, this
can be handled by a server accepting requests containing a Server can be handled by a server accepting requests containing a Server
Cookie based on either its old or new secret for the maximum likely Cookie based on either its old or new secret for the maximum likely
time period of such time skew (see also Section 5.5). time period of such time skew (see also Section 7.1).
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
7. Deployment 7. Operational and Deployment Considerations
The DNS cookies mechanism is designed for incremental deployment and The DNS cookies mechanism is designed for incremental deployment and
to complement the orthogonal techniques in [RFC5452]. Either or both to complement the orthogonal techniques in [RFC5452]. Either or both
techniques can be deployed independently at each DNS server and techniques can be deployed independently at each DNS server and
client. client. Thus installation at the client and server end need not be
synchronized.
In particular, a DNS server or client that implements the DNS COOKIE In particular, a DNS server or client that implements the DNS COOKIE
mechanism can interoperate successfully with a DNS client or server mechanism can interoperate successfully with a DNS client or server
that does not implement this mechanism although, of course, in this that does not implement this mechanism although, of course, in this
case it will not get the benefit of the mechanism and the server case it will not get the benefit of the mechanism and the server
involved might choose to severely rate limit responses. When such a involved might choose to severely rate limit responses. When such a
server or client interoperates with a client or server which also server or client interoperates with a client or server which also
implements the DNS cookies mechanism, they get the weak security implements the DNS cookies mechanism, they get the security benefits
benefits of the DNS Cookies mechanism. of the DNS Cookies mechanism.
7.1 Client and Server Secret Rollover
The longer a secret is used, the higher the probability it has been
compromised. Thus clients and servers are configured with a lifetime
for their secret and rollover to a new secret when that lifetime
expires or earlier due to deliberate jitter as described below. The
default lifetime is one day and the maximum permitted is one month.
To be precise and to make it practical to stay within limits despite
long holiday weekends and daylight savings time shifts and the like,
clients and servers MUST NOT continue to use the same secret in new
requests and responses for more than 36 days and SHOULD NOT continue
to do so for more than 26 hours.
Many clients rolling over their secret at the same time could briefly
increase server traffic and exactly predictable rollover times for
clients or servers might facilitate guessing attacks. For example, an
attacker might increase the priority of attacking secrets they
believe will be in effect for an extended period of time. To avoid
rollover synchronization and predictability, it is RECOMMENDED that
pseudorandom jitter in the range of plus zero to minus at least 40%
be applied to the time until a scheduled rollover of a DNS cookie
secret.
It is RECOMMENDED that a client keep the Client Cookie it is
expecting in a reply until there is no longer an outstanding request
associated with that Client Cookie that the client is tracking. This
avoids rejection of replies due to a bad Client Cookie right after a
change in the client secret.
It is RECOMMENDED that a server retain its previous secret after a
rollover to a new secret for a configurable period of time not less
INTERNET-DRAFT DNS Cookies
than 1 second or more than 5 minutes with default configuration of 2
1/2 minutes. Requests with Server Cookies based on its previous
secret are treated as a correct Server Cookie during that time. When
a server responds to a request containing a old Server Cookie that
the server is treating as correct, the server MUST include a new
Server Cookie in its response.
7.2 Counters
It is RECOMMENDED that implementations include counters of the
occurrences of the various types of requests and responses described
in Section 5.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
8. IANA Considerations 8. IANA Considerations
IANA has assigned the following OPT option value: IANA has assigned the following OPT option value:
Value Name Status Reference Value Name Status Reference
-------- ------ -------- --------------- -------- ------ -------- ---------------
10 COOKIE Standard [this document] 10 COOKIE Standard [this document]
skipping to change at page 21, line 20 skipping to change at page 22, line 20
responses. In particular, they provide no protection against "on- responses. In particular, they provide no protection against "on-
path" adversaries; that is, they provide no protection against any path" adversaries; that is, they provide no protection against any
adversary that can observe the plain text DNS traffic, such as an on- adversary that can observe the plain text DNS traffic, such as an on-
path router, bridge, or any device on an on-path shared link (unless path router, bridge, or any device on an on-path shared link (unless
the DNS traffic in question on that path is encrypted). the DNS traffic in question on that path is encrypted).
For example, if a host is connected via an unsecured IEEE Std 802.11 For example, if a host is connected via an unsecured IEEE Std 802.11
link (Wi-Fi), any device in the vicinity that could receive and link (Wi-Fi), any device in the vicinity that could receive and
decode the 802.11 transmissions must be considered "on-path". On the decode the 802.11 transmissions must be considered "on-path". On the
other hand, in a similar situation but one where 802.11 Robust other hand, in a similar situation but one where 802.11 Robust
Security (WPAv2) is appropriately deployed on the Wi-Fi network Security (WPA2) is appropriately deployed on the Wi-Fi network nodes,
nodes, only the Access Point via which the host is connecting is "on- only the Access Point via which the host is connecting is "on-path"
path" as far as the 802.11 link is concerned. as far as the 802.11 link is concerned.
Despite these limitations, deployment of DNS Cookies on the global Despite these limitations, deployment of DNS Cookies on the global
Internet is expected to provide a significant reduction in the Internet is expected to provide a significant reduction in the
available launch points for the traffic amplification and denial of available launch points for the traffic amplification and denial of
service forgery attacks described in Section 2 above. service forgery attacks described in Section 2 above.
Work is underway in the IETF DPRIVE working group to provide
confidentiality for DNS requests and responses which would be
compatible with DNS cookies.
Should stronger message/transaction security be desired, it is Should stronger message/transaction security be desired, it is
suggested that TSIG or SIG(0) security be used (see Section 3.2); suggested that TSIG or SIG(0) security be used (see Section 3.2);
however, it may be useful to use DNS Cookies in conjunction with however, it may be useful to use DNS Cookies in conjunction with
these features. In particular, DNS Cookies could screen out many DNS these features. In particular, DNS Cookies could screen out many DNS
messages before the cryptographic computations of TSIG or SIG(0) are messages before the cryptographic computations of TSIG or SIG(0) are
required and, if SIG(0) is in use, DNS Cookies could usefully screen required and, if SIG(0) is in use, DNS Cookies could usefully screen
out many requests given that SIG(0) does not screen requests but only out many requests given that SIG(0) does not screen requests but only
authenticates the response of complete transactions. authenticates the response of complete transactions.
An attacker that does not know the Server Cookie could do a variety
of things, such as omitting the COOKIE OPT option or sending a random
Server Cookie. In general, DNS servers need to take other measures,
including rate limiting responses, to protect from abuse in such
cases. See further information in Section 5.2.
When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack
and it should consider a more frequent rollover of its secret. More
rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie.
INTERNET-DRAFT DNS Cookies
9.1 Cookie Algorithm Considerations 9.1 Cookie Algorithm Considerations
The cookie computation algorithm for use in DNS Cookies SHOULD be The cookie computation algorithm for use in DNS Cookies SHOULD be
based on a pseudo-random function at least as strong as 64-bit FNV based on a pseudo-random function at least as strong as 64-bit FNV
(Fowler-Noll-Vo [FNV]) because an excessively weak or trivial (Fowler-Noll-Vo [FNV]) because an excessively weak or trivial
algorithm could enable adversaries to guess cookies. However, in algorithm could enable adversaries to guess cookies. However, in
light of the weak plain-text token security provided by DNS Cookies, light of the lightweight plain-text token security provided by DNS
a strong cryptography hash algorithm may not be warranted in many Cookies, a strong cryptography hash algorithm may not be warranted in
cases, and would cause an increased computational burden. many cases, and would cause an increased computational burden.
Nevertheless there is nothing wrong with using something stronger, Nevertheless there is nothing wrong with using something stronger,
for example, HMAC-SHA256-64 [RFC6234], assuming a DNS processor has for example, HMAC-SHA256 [RFC6234] truncated to 64 bits, assuming a
adequate computational resources available. DNS processors that feel DNS processor has adequate computational resources available. DNS
the need for somewhat stronger security without a significant processors that feel the need for somewhat stronger security without
increase in computational load should consider more frequent changes a significant increase in computational load should consider more
in their client and/or server secret; however, this does require more frequent changes in their client and/or server secret; however, this
frequent generation of a cryptographically strong random number does require more frequent generation of a cryptographically strong
[RFC4086]. See Appendices A and B for specific examples of cookie random number [RFC4086]. See Appendices A and B for specific examples
of cookie computation algorithms.
INTERNET-DRAFT DNS Cookies
computation algorithms.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
10. Implementation Considerations 10. Implementation Considerations
The DNS Cookie Option specified herein is implemented in BIND 9.10 The DNS Cookie Option specified herein is implemented in BIND 9.10
using a experimental option code. using an experimental option code.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Normative References Normative References
[RFC1035] - Mockapetris, P., "Domain names - implementation and [RFC1035] - Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 26, line 12 skipping to change at page 27, line 12
10.17487/RFC6234, May 2011, <http://www.rfc- 10.17487/RFC6234, May 2011, <http://www.rfc-
editor.org/info/rfc6234>. editor.org/info/rfc6234>.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Acknowledgements Acknowledgements
The suggestions and contributions of the following are gratefully The suggestions and contributions of the following are gratefully
acknowledged: acknowledged:
Bob Harold, Paul Hoffman, Gayle Noble, Tim Wicinski Alissa Cooper, Bob Harold, Paul Hoffman, David Malone, Yoav Nir,
Gayle Noble, Dan Romascanu,
Tim Wicinski, Peter Yee
The document was prepared in raw nroff. All macros used were defined The document was prepared in raw nroff. All macros used were defined
within the source file. within the source file.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Appendix A: Example Client Cookie Algorithms Appendix A: Example Client Cookie Algorithms
A.1 A Simple Algorithm A.1 A Simple Algorithm
An simple example method to compute Client Cookies is the FNV-64 A simple example method to compute Client Cookies is the FNV-64 [FNV]
[FNV] of the server IP address and the client secret. That is of the client IP address, the server IP address, and the client
secret. That is
Client Cookie = FNV-64 ( Client Secret | Server IP Address ) Client Cookie =
FNV-64( Client IP Address | Server IP Address | Client Secret )
where "|" indicates concatenation. where "|" indicates concatenation. Some computational resources may
be saved by precomputing FNV-64 through the Client IP Address. (If
the order of the items concatenated above is changed to put the
Server IP Address last, it might be possible to further reduce the
computational effort by pre-computing FNV-64 through the bytes of
both the Client IP Address and the Client Secret but this would
reduce the strength of the Client Cookie and is NOT RECOMMENDED.)
A.2 A More Complex Algorithm A.2 A More Complex Algorithm
A more complex algorithm to calculate Client Cookies is given below. A more complex algorithm to calculate Client Cookies is given below.
It uses more computational resources than the simpler algorithm shown It uses more computational resources than the simpler algorithm shown
in A.1. in A.1.
Client Cookie = HMAC-SHA256-64 ( Client Secret, Client Cookie = HMAC-SHA256-64(
Server IP Address ) Client IP Address | Server IP Address,
Client Secret )
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Appendix B: Example Server Cookie Algorithms Appendix B: Example Server Cookie Algorithms
B.1 A Simple Algorithm B.1 A Simple Algorithm
An example of a simple method producing a 64-bit Server Cookie is the An example of a simple method producing a 64-bit Server Cookie is the
FNV-64 [FNV] of the request IP address, the Client Cookie, and the FNV-64 [FNV] of the request IP address, the Client Cookie, and the
server secret. That is server secret.
Server Cookie = Server Cookie =
FNV-64 ( Server Secret | Request IP Address | Client Cookie ) FNV-64( Client IP Address | Client Cookie | Server Secret )
where "|" represents concatenation. where "|" represents concatenation. (If the order of the items
concatenated was changed, it might be possible to reduce the
computational effort by pre-computing FNV-64 through the bytes of the
Sever Secret and Client Cookie but this would reduce the strength of
the Server Cookie and is NOT RECOMMENDED.)
B.2 A More Complex Algorithm B.2 A More Complex Algorithm
Since the Server Cookie has a variable size, the server can store Since the Server Cookie has a variable size, the server can store
various information in that field as long as it is hard for an various information in that field as long as it is hard for an
adversary to guess the entire quantity used for weak authentication. adversary to guess the entire quantity used for authentication. There
There should be 64 bits of entropy in the Server Cookie; for example should be 64 bits of entropy in the Server Cookie; for example it
it could have a sub-field of 64-bits computed pseudo-randomly with could have a sub-field of 64-bits computed pseudo-randomly with the
the server secret as one of the inputs to the pseudo-random function. server secret as one of the inputs to the pseudo-random function.
Types of additional information that could be stored include a time Types of additional information that could be stored include a time
stamp and/or a nonce. stamp and/or a nonce.
The example below is one variation for the Server Cookie that has The example below is one variation for the Server Cookie that has
been implemented in a beta release of BIND where the Server Cookie is been implemented in BIND 9.10.3 (and later) releases where the Server
128 bits composed as follows: Cookie is 128 bits composed as follows:
Sub-field Size Sub-field Size
--------- --------- --------- ---------
Nonce 32 bits Nonce 32 bits
Time 32 bits Time 32 bits
Hash 64 bits Hash 64 bits
With this algorithm, the server sends a new 128-bit cookie back with With this algorithm, the server sends a new 128-bit cookie back with
every request. The Nonce field assures a low probability that there every request. The Nonce field assures a low probability that there
would be a duplicate. would be a duplicate.
The Time field gives the server time and makes it easy to reject old The Time field gives the server time and makes it easy to reject old
cookies. cookies.
The Hash part of the Server Cookie is the hard-to-guess part. In the The Hash part of the Server Cookie is the hard-to-guess part. In BIND
beta release of BIND, its computation can be configured to use AES,
HMAC-SHA1, or, as shown below, HMAC-SHA256:
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
9.10.3 (and later), its computation can be configured to use AES,
HMAC-SHA1, or, as shown below, HMAC-SHA256:
hash = hash =
HMAC-SHA256-64 ( Server Secret, HMAC-SHA256-64( Server Secret,
(Client Cookie | nonce | time | client IP Address) ) (Client Cookie | nonce | time | Client IP Address) )
where "|" represents concatenation. where "|" represents concatenation.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Huawei Technologies Huawei Technologies
155 Beaver Street 155 Beaver Street
skipping to change at page 30, line 26 skipping to change at page 31, line 26
Mark Andrews Mark Andrews
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 USA Redwood City, CA 94063 USA
Email: marka@isc.org Email: marka@isc.org
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 67 change blocks. 
167 lines changed or deleted 235 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/