Interoperable Domain Name System (DNS) Server Cookies
draft-eastlake-dnsop-server-cookies-00
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2019-07-21
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text