draft-ietf-dnsop-server-cookies-02.txt   draft-ietf-dnsop-server-cookies-03.txt 
DNSOP Working Group O. Sury DNSOP Working Group O. Sury
Internet-Draft Internet Systems Consortium Internet-Draft Internet Systems Consortium
Updates: 7873 (if approved) W. Toorop Updates: 7873 (if approved) W. Toorop
Intended status: Standards Track NLnet Labs Intended status: Standards Track NLnet Labs
Expires: May 21, 2020 D. Eastlake 3rd Expires: November 21, 2020 D. Eastlake 3rd
Futurewei Technologies Futurewei Technologies
M. Andrews M. Andrews
Internet Systems Consortium Internet Systems Consortium
November 18, 2019 May 20, 2020
Interoperable Domain Name System (DNS) Server Cookies Interoperable Domain Name System (DNS) Server Cookies
draft-ietf-dnsop-server-cookies-02 draft-ietf-dnsop-server-cookies-03
Abstract Abstract
DNS cookies, as specified in RFC 7873, are a lightweight DNS DNS cookies, as specified in RFC 7873, are a lightweight DNS
transaction security mechanism that provides limited protection to transaction security mechanism that provides limited protection to
DNS servers and clients against a variety of denial-of-service and DNS servers and clients against a variety of denial-of-service and
amplification, forgery, or cache poisoning attacks by off-path amplification, forgery, or cache poisoning attacks by off-path
attackers. attackers.
This document provides precise directions for creating Server Cookies This document provides precise directions for creating Server Cookies
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2020. This Internet-Draft will expire on November 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
8. Security and Privacy Considerations . . . . . . . . . . . . . 9 8. Security and Privacy Considerations . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11
B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11
B.2. The same client learning a renewed (fresh) Server Cookie 12 B.2. The same client learning a renewed (fresh) Server Cookie 12
B.3. Another client learning a renewed Server Cookie . . . . . 13 B.3. Another client learning a renewed Server Cookie . . . . . 13
B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14
Appendix C. Implementation status . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
DNS cookies, as specified in [RFC7873], are a lightweight DNS DNS cookies, as specified in [RFC7873], are a lightweight DNS
transaction security mechanism that provides limited protection to transaction security mechanism that provides limited protection to
DNS servers and clients against a variety of denial-of-service and DNS servers and clients against a variety of denial-of-service and
amplification, forgery, or cache poisoning attacks by off-path amplification, forgery, or cache poisoning attacks by off-path
attackers. This document specifies a means of producing attackers. This document specifies a means of producing
interoperable strong cookies so that an anycast server set including interoperable strong cookies so that an anycast server set including
skipping to change at page 4, line 41 skipping to change at page 4, line 41
This document has suggestions on Client Cookie construction in This document has suggestions on Client Cookie construction in
Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT
RECOMMENDED. RECOMMENDED.
3. Constructing a Client Cookie 3. Constructing a Client Cookie
The Client Cookie is a cryptographic nonce and should be treated as 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 such. It is RECOMMENDED to create a new Client Cookie for each new
upstream server a Client connects to. The Client Cookie SHOULD have upstream server a Client connects to. The Client Cookie SHOULD have
at least 64-bits of entropy. 64-bits of entropy.
When a Server does not support DNS Cookies, the Client MUST NOT send 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 the same Client Cookie to that same Server again. Instead, it is
recommended that the Client does not send a Client Cookie to that recommended that the Client does not send a Client Cookie to that
Server for a certain period, like for example five minutes, before it Server for a certain period, like for example five minutes, before it
retries with a new Client Cookie. retries with a new Client Cookie.
When a Server does support DNS Cookies, the Client should store the When a Server does support DNS Cookies, the Client should store the
Client Cookie alongside the Server Cookie it registered for that Client Cookie alongside the Server Cookie it registered for that
Server. Server.
skipping to change at page 15, line 22 skipping to change at page 15, line 22
;example.net. IN A ;example.net. IN A
;; ANSWER SECTION: ;; ANSWER SECTION:
example.net. 86400 IN A 192.0.2.34 example.net. 86400 IN A 192.0.2.34
;; Query time: 6 msec ;; Query time: 6 msec
;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53)
;; WHEN: Wed Jun 5 13:36:57 UTC 2019 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019
;; MSD SIZE rcvd: 84 ;; MSD SIZE rcvd: 84
Appendix C. Implementation status
At the time of writing, BIND from version 9.16 and Knot DNS from
version 2.9.0 create Server Cookies according to the recipe described
in this draft. Unbound and NSD have an Proof of Concept
implementation that has been tested for interoperability during the
hackathon at the IETF104 in Prague. Construction of privacy
maintaining Client Cookies according to the directions in this draft
have been implemented in the getdns library and will be in the
upcoming getdns-1.6.1 release and in Stubby version 0.3.1.
Authors' Addresses Authors' Addresses
Ondrej Sury Ondrej Sury
Internet Systems Consortium Internet Systems Consortium
CZ CZ
Email: ondrej@isc.org Email: ondrej@isc.org
Willem Toorop Willem Toorop
NLnet Labs NLnet Labs
 End of changes. 8 change blocks. 
6 lines changed or deleted 18 lines changed or added

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