draft-ietf-dnsop-server-cookies-00.txt   draft-ietf-dnsop-server-cookies-01.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: March 12, 2020 D. Eastlake 3rd Expires: May 7, 2020 D. Eastlake 3rd
Futurewei Technologies Futurewei Technologies
M. Andrews M. Andrews
Internet Systems Consortium Internet Systems Consortium
September 9, 2019 November 4, 2019
Interoperable Domain Name System (DNS) Server Cookies Interoperable Domain Name System (DNS) Server Cookies
draft-ietf-dnsop-server-cookies-00 draft-ietf-dnsop-server-cookies-01
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 March 12, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Contents of this document . . . . . . . . . . . . . . . . 3 1.1. Contents of this document . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Changes to [RFC7873] . . . . . . . . . . . . . . . . . . . . 4 2. Changes to [RFC7873] . . . . . . . . . . . . . . . . . . . . 4
3. Constructing a Client Cookie . . . . . . . . . . . . . . . . 4 3. Constructing a Client Cookie . . . . . . . . . . . . . . . . 4
4. Constructing a Server Cookie . . . . . . . . . . . . . . . . 5 4. Constructing a Server Cookie . . . . . . . . . . . . . . . . 5
4.1. The Version Sub-Field . . . . . . . . . . . . . . . . . . 5 4.1. The Version Sub-Field . . . . . . . . . . . . . . . . . . 6
4.2. The Reserved Sub-Field . . . . . . . . . . . . . . . . . 5 4.2. The Reserved Sub-Field . . . . . . . . . . . . . . . . . 6
4.3. The Timestamp Sub-Field . . . . . . . . . . . . . . . . . 6 4.3. The Timestamp Sub-Field . . . . . . . . . . . . . . . . . 6
4.4. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 6 4.4. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 6
5. Updating the Server Secret . . . . . . . . . . . . . . . . . 6 5. Updating the Server Secret . . . . . . . . . . . . . . . . . 7
6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 8 6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 10
B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 9 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 10
B.2. The same client learning a renewed (fresh) Server Cookie 10 B.2. The same client learning a renewed (fresh) Server Cookie 11
B.3. Another client learning a renewed Server Cookie . . . . . 11 B.3. Another client learning a renewed Server Cookie . . . . . 12
B.4. IPv6 query with rolled over secret . . . . . . . . . . . 12 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
diverse implementations can be easily configured to interoperate with diverse implementations can be easily configured to interoperate with
skipping to change at page 4, line 34 skipping to change at page 4, line 34
server algorithm. This algorithm is replaced by the interoperable server algorithm. This algorithm is replaced by the interoperable
specification in Section 4 of this document, which MUST be used by specification in Section 4 of this document, which MUST be used by
Server Cookie implementations. Server Cookie implementations.
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 nonce and should be treated as such. For The Client Cookie is a cryptographic nonce and should be treated as
simplicity, it can be calculated from Server IP Address, and a secret such. For simplicity, it can be calculated from Server IP Address,
known only to the Client. The Client Cookie SHOULD have at least and a Client Secret known only to the Client that is changed whenever
64-bits of entropy. If a secure pseudorandom function (like an IP address previously used by the Client is no longer available.
[SipHash-2.4]) is used, there's no need to change Client secret The Client Cookie SHOULD have at least 64-bits of entropy.
often. It is reasonable to change the Client secret only if it has
been compromised or after a relatively long period of time such as no Except for when the Client IP address changes, there is no need to
longer than a year. change the Client Secret often if a secure pseudorandom function
(like [SipHash-2.4]) is used. It is reasonable to change the Client
secret then only if it has been compromised or after a relatively
long period of time such as no longer than a year.
It is RECOMMENDED but not required that the following pseudorandom It is RECOMMENDED but not required that the following pseudorandom
function be used to construct the Client Cookie: function be used to construct the Client Cookie:
Client-Cookie = MAC_Algorithm( Client-Cookie = MAC_Algorithm(
Server IP Address, Client Secret ) Server IP Address, Client Secret )
where "|" indicates concatenation.
Previously, the recommended algorithm to compute the Client Cookie Previously, the recommended algorithm to compute the Client Cookie
included Client IP Address as an input to the MAC_Algorithm. included Client IP Address as an input to the MAC_Algorithm.
However, when implementing the DNS Cookies, several DNS vendors found However, when implementing the DNS Cookies, several DNS vendors found
impractical to include the Client IP as the Client Cookie is impractical to include the Client IP as the Client Cookie is
typically computed before the Client IP address is known. Therefore, typically computed before the Client IP address is known. Therefore,
the requirement to put Client IP address as input to was removed, and the requirement to put Client IP address as input was removed.
it simply RECOMMENDED to disable the DNS Cookies when privacy is
required. However, for privacy reasons, in order to prevent tracking of devices
across links and to not circumvent IPv6 Privacy Extensions [RFC4941],
Clients MUST NOT re-use a Client or Server Cookie after the Client IP
address has changed.
The Client IP address is available on the UDP socket when it receives
the Server Cookie and should be registered alongside the Server
Cookie. In subsequent queries to the Server with that Server Cookie,
the socket MUST be bound to the Client IP address that was also used
(and registered) when it received the Server Cookie. Failure to bind
must result in a new Client Cookie, which, for the method described
in this section means a new Client Secret.
4. Constructing a Server Cookie 4. Constructing a Server Cookie
The Server Cookie is effectively a Message Authentication Code (MAC) The Server Cookie is effectively a Message Authentication Code (MAC)
and should be treated as such. The Server Cookie is calculated from and should be treated as such. The Server Cookie is calculated from
the Client Cookie, a series of Sub-Fields specified below, the Client the Client Cookie, a series of Sub-Fields specified below, the Client
IP address, and a Server Secret known only to the servers responding IP address, and a Server Secret known only to the servers responding
on the same address in an anycast set. on the same address in an anycast set.
Changing the Server Secret regularly is RECOMMENDED but, when a Changing the Server Secret regularly is RECOMMENDED but, when a
skipping to change at page 6, line 34 skipping to change at page 6, line 46
4.4. The Hash Sub-Field 4.4. The Hash Sub-Field
It's important that all the DNS servers use the same algorithm for It's important that all the DNS servers use the same algorithm for
computing the Server Cookie. This document defines the Version 1 of computing the Server Cookie. This document defines the Version 1 of
the Server Side algorithm to be: the Server Side algorithm to be:
Hash = SipHash2.4( Hash = SipHash2.4(
Client Cookie | Version | Reserved | Timestamp | Client-IP, Client Cookie | Version | Reserved | Timestamp | Client-IP,
Server Secret ) Server Secret )
where "|" indicates concatenation.
Notice that Client-IP is used for hash generation even though it's Notice that Client-IP is used for hash generation even though it's
not included in the cookie value itself. Client-IP can be either 4 not included in the cookie value itself. Client-IP can be either 4
bytes for IPv4 or 16 bytes for IPv6. bytes for IPv4 or 16 bytes for IPv6.
The Server Secret MUST be configurable to make sure that servers in The Server Secret MUST be configurable to make sure that servers in
an anycast network return consistent results. an anycast network return consistent results.
5. Updating the Server Secret 5. Updating the Server Secret
All servers in an anycast group must be able to verify the Server All servers in an anycast group must be able to verify the Server
skipping to change at page 9, line 41 skipping to change at page 10, line 13
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks to Witold Krecicki and Pieter Lexis for valuable input, Thanks to Witold Krecicki and Pieter Lexis for valuable input,
suggestions and text and above all for implementing a prototype of an suggestions and text and above all for implementing a prototype of an
interoperable DNS Cookie in Bind9, Knot and PowerDNS during the interoperable DNS Cookie in Bind9, Knot and PowerDNS during the
hackathon of IETF104 in Prague. Thanks for valuable input and hackathon of IETF104 in Prague. Thanks for valuable input and
suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin
Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob
Harold Harold and Philip Homburg
Appendix B. Test vectors Appendix B. Test vectors
B.1. Learning a new Server Cookie B.1. Learning a new Server Cookie
A resolver (client) sending from IPv4 address 198.51.100.100, sends a A resolver (client) sending from IPv4 address 198.51.100.100, sends a
query for "example.com" to an authoritative server listening on query for "example.com" to an authoritative server listening on
192.0.2.53 from which it has not yet learned the server cookie. 192.0.2.53 from which it has not yet learned the server cookie.
The DNS requests and replies shown in this Appendix, are in a "dig" The DNS requests and replies shown in this Appendix, are in a "dig"
 End of changes. 14 change blocks. 
31 lines changed or deleted 44 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/