--- 1/draft-ietf-dnsop-server-cookies-02.txt 2020-05-20 12:13:09.198634822 -0700 +++ 2/draft-ietf-dnsop-server-cookies-03.txt 2020-05-20 12:13:09.218635106 -0700 @@ -1,23 +1,23 @@ DNSOP Working Group O. Sury Internet-Draft Internet Systems Consortium Updates: 7873 (if approved) W. Toorop Intended status: Standards Track NLnet Labs -Expires: May 21, 2020 D. Eastlake 3rd +Expires: November 21, 2020 D. Eastlake 3rd Futurewei Technologies M. Andrews Internet Systems Consortium - November 18, 2019 + May 20, 2020 Interoperable Domain Name System (DNS) Server Cookies - draft-ietf-dnsop-server-cookies-02 + draft-ietf-dnsop-server-cookies-03 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 provides precise directions for creating Server Cookies @@ -34,25 +34,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on May 21, 2020. + This Internet-Draft will expire on November 21, 2020. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 @@ -76,20 +76,21 @@ 8. Security and Privacy Considerations . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11 B.2. The same client learning a renewed (fresh) Server Cookie 12 B.3. Another client learning a renewed Server Cookie . . . . . 13 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14 + Appendix C. Implementation status . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 @@ -168,21 +169,21 @@ This document has suggestions on Client Cookie construction in Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT RECOMMENDED. 3. Constructing a Client Cookie 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 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 the same Client Cookie to that same Server again. Instead, it is recommended that the Client does not send a Client Cookie to that Server for a certain period, like for example five minutes, before it retries with a new Client Cookie. When a Server does support DNS Cookies, the Client should store the Client Cookie alongside the Server Cookie it registered for that Server. @@ -653,20 +654,31 @@ ;example.net. IN A ;; ANSWER SECTION: example.net. 86400 IN A 192.0.2.34 ;; Query time: 6 msec ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 ;; 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 Ondrej Sury Internet Systems Consortium CZ Email: ondrej@isc.org Willem Toorop NLnet Labs