Internet DRAFT - draft-eastlake-dnsop-server-cookies
draft-eastlake-dnsop-server-cookies
INTERNET-DRAFT D. Eastlake
Intended Status: Proposed Standard Futurewei
Updates: 7873 M. Andrews
ISC
Expires: January 20, 2020 July 21, 2019
Interoperable Domain Name System (DNS) Server Cookies
<draft-eastlake-dnsop-server-cookies-00.txt>
Abstract
DNS 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 specifies a means of producing interoperable
strong cookies so that an anycast server set including diverse
implementations will interoperate with standard clients. This
document updates RFC 7873.
Status of This Document
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the author or the DNSOP mailing list <dnsop@ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Donald Eastlake & Mark Andrews [Page 1]
INTERNET-DRAFT Interoperable DNS Cookies
Table of Contents
1. Introduction............................................3
1.2 Definitions............................................3
2. Changes to [RFC7873]....................................4
3. Interoperable Server Cookie Configuration...............5
4. Server Cookie Calculations..............................6
4.1 Individual Server Cookie Calculation...................6
4.2 ServerSecret Calculation Schedule......................7
4.3 Initialization.........................................8
5. IANA Considerations.....................................9
6. Security Considerations.................................9
Normative References......................................10
Informative References....................................10
Acknowledgements..........................................11
Author's Address..........................................12
Donald Eastlake & Mark Andrews [Page 2]
INTERNET-DRAFT Interoperable DNS Cookies
1. Introduction
DNS cookies, as specified in [RFC7873], 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 [RFC7873].
In the case of an anycast set of DNS servers, it is desirable for any
server in the set to be able to validate a server cookie recently
provided to a client by a different server in the set. If such a
server cookie is not recognized, it will typically result in one or
more additional roundtrips increasing volume of traffic and final
response latency.
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.
1.2 Definitions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
"Floor" is the function returning the integer part of its argument.
That is, Floor(x) is the largest integer not greater than x.
"HMAC-SHA265-xx" is the HMAC [RFC2104] hash function using SHA-256
[RFC6234] truncated to xx bits.
"Off-path attacker", for a particular DNS client and server, is
defined as an attacker who cannot observe the DNS request and
response messages between that client and server.
"IP Address" is used herein as a length independent term covering
both IPv4 and IPv6 addresses.
Donald Eastlake & Mark Andrews [Page 3]
INTERNET-DRAFT Interoperable DNS Cookies
2. Changes to [RFC7873]
In its Appendices A.1 and B.1 [RFC7873] provides example "simple"
algorithms for computing Client and Server Cookies, respectively.
These algorithms are NOT RECOMMENDED as the cookies produces 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 Section 4 of this document, which is RECOMMENDED.
There is no reason for client cookies to be interoperable as clients
need only recognize their own cookies, which are returned in the
response to their queries. Thus, Appendix A.2 of [RFC7873] is
unchanged.
Donald Eastlake & Mark Andrews [Page 4]
INTERNET-DRAFT Interoperable DNS Cookies
3. Interoperable Server Cookie Configuration
The calculation of interoperable server cookies is determined by two
configuration parameters: CookieMaster and SecretDuration. Methods
of distributing these two parameters to the DNS servers in an anycast
set are beyond the scope of this document but such methods MUST NOT
reveal CookieMaster to adversaries who might try to forge server
Cookies and SHOULD NOT reveal SecretDuration to such adversaries.
CookieMaster is the master secret used in deriving the
interoperable server cookies. It is a byte string not longer
than 255 bytes. It SHOULD NOT be shorter than 12 bytes and
SHOULD have at least 96 bits of entropy [RFC4086].
SecretDuration is a parameter that determines when, on average,
the server rolls over the derived secret used in calculating
server cookies. It is a 16-bit quantity giving the average
seconds between rollovers as an unsigned integer. Values
less than 16 are Interpreted as being equal to 16. The
maximum time that can be represented is 18 hours 12 minutes
and 15 seconds.
Donald Eastlake & Mark Andrews [Page 5]
INTERNET-DRAFT Interoperable DNS Cookies
4. Server Cookie Calculations
The calculations and internal variables specified in this section are
logical. Any other calculations and variables yielding the same
Server Cookies may be used.
Particular Server Cookies are calculated as specified in Section 4.1.
How and when the derived ServerSecret, used in calculating Server
Cookies, is calculated is specified in Section 4.2. And
initialization considerations are covered in Section 4.3.
State variables needed by the DNS server for this purpose, in
addition to the configuration quantities give in Section 3, are as
follows:
ServerSecret is a 128-bit quantity periodically derived from
CookieMaster as specified in Section 4.2.
Time is 64 bits and gives the time since the beginning of January 1,
1900, in seconds ignoring leap seconds, as an unsigned
integer in network byte order.
K is a 32-bit unsigned integer representing the ServerSecret epoch.
4.1 Individual Server Cookie Calculation
The value of an interoperable server cookie is a 128-bit quantity
structured as follows:
<--- 4 bytes --->
+-------------------+
| Nonce | 32 bits
+-------------------+
| Time | 32 bits
+-------------------+
| |
+- Hash -+ 64 bits
| |
+-------------------+
Nonce = a 32-bit locally generated random number [RFC4086] which
SHOULD have 32 bits of entropy. The presence of the nonce
field assures a very low probability that there would be
duplicate cookies.
Time = the Time state variable defined above. The presence of
this field makes it easy to reject old cookies (unless they
are very old (close to some exact multiple of 2**32 seconds
Donald Eastlake & Mark Andrews [Page 6]
INTERNET-DRAFT Interoperable DNS Cookies
(a little over 136 years) ago and you are still using the
same CookieMaster secret).
Hash = The Hash part of the Server Cookie is the hard-to-guess
part. (The Nonce and the Time appear in plain text.) It is
calculated in a two-stage process. First, the ServerSecret
is occasionally calculated at the times and by the method
specified in Section 4.2. Then the Hash is calculated using
the ServerSecret as show further below.
Whenever a server needs a Server Cookie to include in a
reply, it calculates the Hash field of that Server Cookie
as follows:
Hash =
HMAC-SHA256-64( ServerSecret,
( Client Cookie | Nonce | Time | Client IP Address) )
where "|" represents concatenation and the "Client Cookie"
is as specified in [RFC7873].
With this method, a server sends a new 128-bit cookie back with every
request.
4.2 ServerSecret Calculation Schedule
A different Server Secret is used for each time epoch. Epoch k covers
the seconds numbered (see definition of Time above) from
EpochStart(k) to EpochStart(k+1)-1.
The ServerSecret used during epoch K is
ServerSecret =
HMAC-SHA256-128( "DNSCookie",
( EpochStart(K) | CookieMaster | EpochStart(K) ) )
where "|" represents concatenation and "DNSCookie" is that 9 byte
ASCII [RFC20] string without any zero termination byte.
As describe in Section 7.1 of [RFC7873], it is desirable for jitter
to be applied to the time of updating the key being used by the
servers in an anycast group. Including pseudo random jitter, the
start time of epoch K is as follows:
EpochStart( K ) =
K*SecretDuration +
Floor((HMAC-SHA256-32("DNSjitter",
K | CookieMaster)%SecretDuration)*8/10)
Donald Eastlake & Mark Andrews [Page 7]
INTERNET-DRAFT Interoperable DNS Cookies
where "|" is concatenation, "%" is the modulus operator (x%y is the
remainder of x divided by y), and the output of HMAC-SHA256-32 is
considered a 32-bit unsigned integer.
If Time < EpochStart(K+1), then ServerSecret is up to date. If Time
>= EpochStart(K+1), then ServerSecret needs to be updated as
specified at the beginning of this section and K is incremented.
There are various strategies for keeping ServerSecret up do date. The
test at the beginning of this paragraph and conditional update of
ServerSecret could be done once a second. However, it would be more
efficient, when that test is done, to save EpochStart(K+1) as the
next time the test and conditional updates should be performed.
4.3 Initialization
Whenever the value of SecretDuration or CookieMaster or both is set
of if a significant change is made to Time, the steps in this section
MUST run before any Server Cookies are generated. (A change to Time
is significant if the first two steps below would result in a value
for K different from the current value.)
o K is set to Floor(Time/SecretDuration).
o If Time < EpochStart(K), then set K to K-1.
o Calculate and set ServerSecret as specified at the beginning of
Section 4.2.
Donald Eastlake & Mark Andrews [Page 8]
INTERNET-DRAFT Interoperable DNS Cookies
5. IANA Considerations
This document requires no IANA actions.
6. Security Considerations
The minor adjustments to the Server Cookie calculation algorithm made
by this document do not affect the security considerations provided
in [RFC7873].
Donald Eastlake & Mark Andrews [Page 9]
INTERNET-DRAFT Interoperable DNS Cookies
Normative References
[RFC20] - Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-
editor.org/info/rfc20>.
[RFC2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, DOI
10.17487/RFC2104, February 1997, <https://www.rfc-
editor.org/info/rfc2104>.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, DOI
10.17487/RFC4086, June 2005, <http://www.rfc-
editor.org/info/rfc4086>.
[RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
10.17487/RFC6234, May 2011, <http://www.rfc-
editor.org/info/rfc6234>.
[RFC7873] - Eastlake 3rd, D. and M. Andrews, "Domain Name System
(DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>.
Informative References
None.
Donald Eastlake & Mark Andrews [Page 10]
INTERNET-DRAFT Interoperable DNS Cookies
Acknowledgements
The suggestions and contributions of the following are gratefully
acknowledged:
Petr Spacek
Donald Eastlake & Mark Andrews [Page 11]
INTERNET-DRAFT Interoperable DNS Cookies
Author's Address
Donald E. Eastlake 3rd
Futurewei Technologies
1424 Pro Shop Court
Davenport, FL 33896 USA
Telephone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Mark Andrews
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063 USA
Email: marka@isc.org
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Donald Eastlake & Mark Andrews [Page 12]
