Subject: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.txt

From: [email-masked]
Date: Mon, 04 Nov 2019 12:58:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Interoperable Domain Name System (DNS) Server Cookies
        Authors         : Ondrej Sury
                          Willem Toorop
                          Donald E. Eastlake 3rd
                          Mark Andrews
	Filename        : draft-ietf-dnsop-server-cookies-01.txt
	Pages           : 15
	Date            : 2019-11-04

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
   so that an anycast server set including diverse implementations will
   interoperate with standard clients.

   This document updates [RFC7873]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Willem Toorop <[email-masked]>
Date: Wed, 6 Nov 2019 16:26:18 +0100

Dear dnsop,

This version has an updated Client Cookie construction section in which
it is now REQUIRED to change a Client Cookie when the Client IP address
changes.

Previously (in versions before the previous version) the Client IP
address was used in Cookie construction, however that turned out to be
impractical to implement and therefore dropped from the previous version
recommending to disable DNS Cookies when privacy was a requirement.

Philip Homburg pointed out that, although impractical to determine the
Client IP before Client Cookie construction, it is feasible for a Client
to detect it when it learns a Server Cookie from a specific Server.  It
can subsequently be tried to be reused for the same Server which will
fail if the Client IP has changed.

This new (and practically implementable) requirement does not only
enhance privacy and make DNS Cookies work with the IPv6 Privacy
Extensions (by preventing tracking), it also makes them work in other
environments where Client source IP can change frequently, such as in
setups with multiple outgoing gateways.

Op 04-11-2019 om 21:58 schreef [email-masked]:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Nov 2019 17:27:50 +0100

>setups with multiple outgoing gateways.

Note that my preference was a pseudo-random client cookie. 

I can see two issues with the current approach:
1) I'm not sure this actually fixes the IPv6 privacy extensions problem.
   The same client cookie can be used on different addresses if the 
   server doesn't support cookies and the client at some point forgets
   that the server doesn't support cookies (and sends the server the
   same client cookie after a new privacy address is generated).

2) As an extension of the previous, if no server supports cookies, then the
   client will not change the Client Secret and continues to use the same
   client cookie after it moves to new location.

---

From: Willem Toorop <[email-masked]>
Date: Thu, 7 Nov 2019 10:04:08 +0100

>    client cookie after it moves to new location.

Ack!

I see e need to adapt Client Construction section again. Also, these
considerations should be well expressed in a privacy and security
section as well.