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

From: [email-masked]
Date: Mon, 09 Sep 2019 03:26:10 -0700

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-00.txt
	Pages           : 14
	Date            : 2019-09-09

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-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-00

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: Mon, 9 Sep 2019 14:13:01 +0200

Hi All,

The only change since the previous version (i.e.
draft-sury-toorop-dnsop-server-cookies-00) is that we no longer
recommend to include the Client IP address with constructing client cookies:

When implementing DNS Cookies, several DNS vendors found that
impractical as the Client Cookie is typically computed before the Client
IP address is known. Therefore, the requirement to put Client IP address
as input to was removed, and it simply RECOMMENDED to disable the DNS
Cookies when privacy is required. herefore, the requirement to put
Client IP address as input to was removed, and it simply RECOMMENDED to
disable the DNS Cookies when privacy is required.

-- Willem

On 09-09-19 12:26, [email-masked] wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2019 08:52:31 -0400 (EDT)

> disable the DNS Cookies when privacy is required.

Wouldn't this enable me to obtain some cookies from within a network,
and then re-use those cookies from outside the network? The reason for
including the IP was the pin the cookie to the specific client IP.

I cannot see a diff because you didn't instruct the data tracker that
this adopted document continues from the individual submission :(

I was going to look at the diff to the security section, but I guess
there is none because the document does not yet contain a security
section. But I would expect a good write up of the impact of not
including the IP address in a cookie in that section.

Paul

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Sep 2019 15:45:14 +0200

>disable the DNS Cookies when privacy is required.

I don't quite understand this.

The proposed way of constructing a client cookie:
	Client-Cookie = MAC_Algorithm(Server IP Address, Client Secret )

means that if a host moves between networks it is quite likely it will
continue to use the same cookie. This allows a host to be tracked across
networks.

Neither RFC 7873 nor this draft has text that requires the host to change
the Client Secret when moving to a different link. 

Most DNS client software is general enough that we cannot rule out that it
will be used on a mobile device.

So we reach then end of Section 3, which says '[...] simply RECOMMENDED
to disable the DNS Cookies when privacy is required'

So it seems that this draft implicitly recommends that DNS client
cookies are by default disabled and should only be enabled on hosts that have
stable IP addresses.

If that's the intention, then maybe this can be stated explicitly in the
introduction.

---

From: Willem Toorop <[email-masked]>
Date: Mon, 9 Sep 2019 15:51:26 +0200

> including the IP was the pin the cookie to the specific client IP.

No, Client IP is still included in *Server* Cookie generation, just not
in Client Cookie construction.  So the re-user from different network
protection is still there.

> this adopted document continues from the individual submission :(

Oh, sorry.  I indicated that it replaced the previous draft (and
Donald's) that is not correct?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2019 10:02:26 -0400 (EDT)

> protection is still there.

Ohh, I misunderstood that. Perhaps note this down in the to be Security
Section :)

> Donald's) that is not correct?

That normally ensures the datatracker does the tracking and the diffs,
but it does not look like that happened for this document. It appears
as a fresh submit without any history. Even weirder, it seems that the
old document indeed got the update reference:

https://tools.ietf.org/html/draft-sury-toorop-dnsop-server-cookies-00

but the new document does not link back to the old one and misses the
diff.

I CC:ed the tools team on this who might be able to see/fix what happened?

Paul

---

From: Willem Toorop <[email-masked]>
Date: Mon, 9 Sep 2019 16:08:24 +0200

> continue to use the same cookie. This allows a host to be tracked across

This is true.  Including the Client IP in constructing the Client Cookie
was intended to deal with this, but this operation is impractical with
UDP; expensive at best and not suitable for high volume recursive to
authoritative traffic.

We could recommend it for stub to recursive traffic, for which the high
volume performance requirements are less of an issue... what do you think?

> introduction.>

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 Sep 2019 10:19:51 -0400

Paul:

The replaces and replaced-by information comes from the submitter.  In this case:

	Set submitter to "Willem Toorop <[email-masked]>", replaces to draft-sury-toorop-dnsop-server-cookies, draft-eastlake-dnsop-server-cookies

> I CC:ed the tools team on this who might be able to see/fix what happened?

It looks like there are four drafts in the replaced-by history:

	draft-sury-toorop-dns-cookies-algorithms
	draft-sury-toorop-dnsop-server-cookies
	draft-eastlake-dnsop-server-cookies
	draft-ietf-dnsop-server-cookies

The history tab of draft-ietf-dnsop-server-cookies shows all four, allowing the comparison of the last one to any of the earlier ones.

Russ

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Sep 2019 16:56:21 +0200

>volume performance requirements are less of an issue... what do you think?

Maybe high volume should be the exception.

I think it is better to specify that all code should include the Client IP
unless explicitly configured to leave it out.

A bit of testing suggests that a naive way of getting the Client IP takes 
about 2 microseconds on modern hardware. So a bit of caching on high 
performance resolvers would be enough.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 Sep 2019 10:41:47 -0500

This looks correct to me both on the datatracker and at tools.ietf.org.

If there's still something that's not right, please bring focus to it.

RjS

On 9/9/19 9:19 AM, Russ Housley wrote:
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Sep 2019 18:14:22 +0200

>as input to was removed, 

In Section 4.4, the client IP is added to the hash in the creation of the
server cookie.

I wonder what happens if a client alternates between different IP addresses,
for example, the client has multiple interfaces, the client has multiple
IPv6 prefixes on a single interface or a CGNAT device regards different DNS
requests as independent UDP flows and assigns them to different parts of
a CGNAT system.

It is possible that in those cases, a server would force a client to
retry for every request.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2019 12:29:15 -0400 (EDT)

In the top bar, there is no mention of the previous or current version,
despite that if you click "diff2", you see a diff to a previous version.

Compare it to a random other document:

https://tools.ietf.org/html/draft-wang-ipsecme-ike-yang-00

There is no previous document here, yet the top bar shows:

 	Versions: 00

Paul

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 Sep 2019 12:38:11 -0400

> On Sep 9, 2019, at 12:29 PM, Paul Wouters <[email-masked]> wrote:
> 

That is a volunteer maintained tool.

Please look here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/>

Russ

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 Sep 2019 11:39:35 -0500

Hi Paul -

At https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-00, I see

Versions: (draft-sury-toorop-dnsop-server-cookies 
<https://tools.ietf.org/html/draft-sury-toorop-dnsop-server-cookies>) 00 
<https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-00>

RjS

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2019 12:53:01 -0400 (EDT)

On Mon, 9 Sep 2019, Robert Sparks wrote:

> Versions: (draft-sury-toorop-dnsop-server-cookies) 00

Funny :P

Some{thing|one} fixed it. It now shows up properly.

Paul

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Sep 2019 20:59:30 +0200

>In Section 4.4, the client IP is added to the hash in the creation of the

Ah, never mind, that is already in RFC 7873.

So a client that wants to (re-)use a server cookie needs to know the
source address it previously used to communicate with the server.
So if the client maintains that kind of state (and sends follow up traffic
only from the recorded source address), then the client can just as well
use a new pseudo-random client cookie each time the client creates new
state. No need to include the client IP address in the cookie or worry 
about the cookie leaking. The send off the packet will fail if the 
source address is no long available.