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