Subject: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

From: Tim Wicinski <[email-masked]>
Date: Thu, 4 Aug 2016 20:03:35 -0400

All

Remember the Resolver Priming draft? This thing has been kicking around 
for a good solid 5 years. It stalled for a few years waiting for the 
busy authors perform some updates.
Then Paul Hoffman took the reins and has done a great job getting this 
ready for publication.

This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-priming

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on 19 
August, 2016

thanks
tim

---

From: Shane Kerr <[email-masked]>
Date: Fri, 5 Aug 2016 11:45:11 +0200

All,

At 2016-08-04 20:03:35 -0400

> Then Paul Hoffman took the reins and has done a great job getting this 

w00t

I like this document, and am happy that it is moving again. :)
 
> feels the document is *not* ready for publication, please speak out with 

I have two minor comments, which may not require any changes.

First, we have:

  "If a priming query does not get a response within 2 seconds, the
  recursive resolver SHOULD retry with a different target address from
  the configuration."

The "2 seconds" seems a bit arbitrary. I'm not sure why any
recommendations need to be made at all. The document already says that
these are basically normal DNS queries elsewhere - surely that is enough? 
(And maybe if we do want to recommend a retry then we need to be clear
that if an answer comes from an earlier query that the resolver may
accept it?)

Second, a possible additional security consideration is that a priming
query typically signals a resolver starting with an empty cache
(although not always - the Knot resolver has a persistent cache, for
example). This may be an especially vulnerable time for a resolver for
cache poisoning. I don't know what can be done to mitigate this though
aside from requiring TCP or DNS cookies for a time after startup, so
perhaps this can be left out.

Cheers,

--
Shane

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 10 Aug 2016 17:38:25 -0700

On 5 Aug 2016, at 2:45, Shane Kerr wrote:

> The "2 seconds" seems a bit arbitrary.

Yep. But...

> I'm not sure why any

The queries are normal, but the reliance on them is not. Without 
priming, nothing can be answered, so that makes them kinda special.

> that if an answer comes from an earlier query that the resolver may

That would be a radical shift. Instead, how about "If a priming query 
does not get a response within a short period (for example, 2 seconds), 
..."?

> perhaps this can be left out.

Priming queries happen both when there is an empty cache and at timeout 
of the root records. Unless we know for sure what the ratio between 
those two are, I'm hesitant to put anything in the document saying that 
it is "common".

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Thu, 11 Aug 2016 12:11:36 -0400

>> I like this document, and am happy that it is moving again. :)
BH:  I also like the document!

> The queries are normal, but the reliance on them is not. Without priming,
> nothing can be answered, so that makes them kinda special.

It seems unnecessary to say much here, trying each of the NS records, and
retrying multiple times, should be 'normal' although the details will be
implementation dependent.  Also related is what to do if none of the
servers respond, but again that is application dependent and we don't want
to go down that trail.

> That would be a radical shift. Instead, how about "If a priming query does
> not get a response within a short period (for example, 2 seconds), ..."?
>
> Priming queries happen both when there is an empty cache and at timeout of
> the root records. Unless we know for sure what the ratio between those two
> are, I'm hesitant to put anything in the document saying that it is
> "common".

Priming queries happen 1) at startup, 2) when cache is emptied (by rndc
flush for example), 3) when the TTL's expire, and 4) when the server
decides to prefetch.  Perhaps there are others, but in every case there are
the same security concerns - an attacker can:  a) inject malicious data, or
b) block valid data from reaching the server.  The first 'owns' the server,
the second disables it.

>
>
> --Paul Hoffman
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Andreas Gustafsson <[email-masked]>
Date: Sat, 13 Aug 2016 14:01:52 +0300

> priming, nothing can be answered, so that makes them kinda special.

It's not necessarily the case that nothing can be answered.
Resolvers can and do resolve user queries using the configured root
servers while priming is in progress.

There is nothing wrong with existing resolvers that use the same
timeout and retransmission strategies for priming queries as for any
other query, and it seems wrong to me that a specific retransmission
timeout should be required for some queries but not others.
-- 
Andreas Gustafsson, [email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 14 Aug 2016 16:27:24 -0700

> that if an answer comes from an earlier query that the resolver may

It's sounding like people don't like the mention of a time at all. 
Proposed replacement:

If a priming query does not get a response within a short time, the 
recursive resolver needs to retry the query with a different target 
address from the configuration.

(I am avoiding saying "within a configured time" because I don't think 
this is easily configured in some common recursors.)

> perhaps this can be left out.

Proposed wording:

An on-path attacker who sees a priming query coming from a resolver can 
inject false answers before a root server can give correct answers. If 
the attacker's answers are accepted, this can set up the ability to give 
further false answers for future queries to the resolver. False answers 
for root servers are more dangerous than, say, false answers for TLDs 
because the root servers are the highest node of the DNS.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Aug 2016 12:04:52 -0500

On Sun, Aug 14, 2016 at 6:27 PM, Paul Hoffman <[email-masked]> wrote:
> It's sounding like people don't like the mention of a time at all. Proposed
> replacement:
>
> recursive resolver needs to retry the query with a different target address
> from the configuration.
>
> (I am avoiding saying "within a configured time" because I don't think this
> is easily configured in some common recursors.)

This sounds fine / good to me -- or perhaps even:
"If a priming query does not get a response, the
recursive resolver needs to retry the query with a different target address
from the configuration."

s/ within a short time//.

This avoids the obvious "What did you mean by 'short'?!" question. IMO
implementors can make their own decision here.

W

> inject false answers before a root server can give correct answers. If the
> attacker's answers are accepted, this can set up the ability to give further
> false answers for future queries to the resolver. False answers for root
> servers are more dangerous than, say, false answers for TLDs because the
> root servers are the highest node of the DNS.
>
> --Paul Hoffman
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 15 Aug 2016 10:44:17 -0700

> is easily configured in some common recursors.)

Since root-servers.net is not signed, recursor also has to deal with
compatibility problems, such as EDNS stripping for example. I wonder
how much should be clarified. I was a bit surprised the
root-servers.net is still unsigned, is this deliberate or what would
it take to sign it? It's a critical zone, and signing it would make
this draft much shorter.

Marek

---

From: 神明達哉 <[email-masked]>
Date: Mon, 15 Aug 2016 18:44:17 -0700

At Sat, 13 Aug 2016 14:01:52 +0300,

> timeout should be required for some queries but not others.

+1.  This is actually I thought in my own read of the draft.
Mentioning a specific timeout value seems a clear overkilling (with no
apparent reason) to me, and while I wouldn't be necessarily opposed to
mentioning the retry at all, it's still awkward to me.  So I'd be
happier if it's simply removed.

--
JINMEI, Tatuya

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 19 Aug 2016 12:41:05 -0400

All

The WGLC last call for resolver-priming has concluded. There was a solid 
number of good reviews, and no reasons to not publish this.

I want to thank everyone who gave reviews and feedback. I'm going to go 
over the list with the author(s) and make sure everything was covered.

thanks
tim

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Aug 2016 12:33:25 +0000

On 8/4/16, 20:03, "DNSOP on behalf of Tim Wicinski" <[email-masked] on behalf of [email-masked]> wrote:
>Remember the Resolver Priming draft?

Comments on the draft (https://tools.ietf.org/id/draft-ietf-dnsop-resolver-priming-07.txt):

## 3.3.  DNSSEC with Priming Queries
##
##    The resolver MAY set the DNSSEC OK [RFC4033] bit.  At the time this
##    document is being published, there is little use to performing DNSSEC
##    validation on the priming query because the "root-servers.net" zone
##    is not signed, and so a man-in-the-middle attack on the priming query
##    can result in malicious data in the responses.  However, if the
##    "root-servers.net" zone is later signed, or if the root server
##    operators choose a different zone to identify themselves and that
##    zone is signed, having DNSSEC validation for the priming queries
##    might be valuable.

Recommend against altering the trust anchor settings based on anything learned via priming.  Not that a priming query would contain DS or DNSKEY resources records "normally" (and thus should not have them) but if the idea to "push" additional records comes around again, the priming query is not the place to also update the secure entry points.

In section 4.2:

##    For an EDNS response, a resolver SHOULD consider the address
##    information found in the Additional section complete for any
##    particular server that appears at all.  Said another way: in an EDNS
##    response, if the additional section only has an A RRSet for a server,
##    the resolver SHOULD assume that no AAAA RRSet exists.

Is "an EDNS response" a term well-enough defined to be used this way?

A possible rewording ought to include - if the priming query contained, via EDNS, Requestor's Payload Size of more than XXY bytes, the address information...complete.  But this assumes that the priming query Size was large enough, e.g., it wasn't set to be 515 bytes.

## 5.  Security Considerations
##
##    Spoofing a response to a priming query can be used to redirect all of
##    the queries originating from a victim recursive resolver to one or
##    more servers for the attacker.  Until the responses to priming
##    queries are protected with DNSSEC, there is no definitive way to
##    prevent such redirection.

There is one use case I'm concerned about - because it has happened.

http://research.dyn.com/2008/05/identity-theft-hits-the-root-n-1/

In so much as at that article is true, a defense that can be used is to recommend multiple (2 or 3) priming queries and have the receiver check for consistency.  Two might indicate a problem, three can point out which is a problem.  In the absence of DNSSEC validation and the observation that Root System changes happen one at a time and fairly well spread out in time, this might be beneficial to recommend.

I offer this just as a suggestion.  (I've been told my major operators that having at least three sources of information increases reliability.  I'm basing my comment on that, more so than the linked story.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 23 Aug 2016 12:32:28 +0200

On Thu, Aug 04, 2016 at 08:03:35PM -0400,
 Tim Wicinski <[email-masked]> wrote 

> This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-priming

I know, it's too late (damned holidays) but I think the document is
OK, I just suggest a few additions:

Section 3.3: Replace the first two sentences by:

The resolver MAY set the DNSSEC OK [RFC4033] bit.  At the time this
document is being published, there is little use to performing DNSSEC
validation on the priming query. This is because all root name servers
are under a separate zone, "root-servers.net" (delegated to the root
name servers). The resolver will eventually need AAAA and A RRsets of
the NS names in this zone. But the "root-servers.net" zone is not
signed. So a man-in-the-middle attack on the priming query can result
in malicious data in the responses.

(it was proposed and explained in
<https://mailarchive.ietf.org/arch/msg/dnsop/c09YZDWvSbcuNxQbDshICQdW5IE>)

Same section 3.3, at the end, add:

Note a validating resolver won't accept responses from rogue root name
servers, if they are different from the real responses, since the
resolver has a trust anchor for the root and the answers from the root
are signed. So, if there is a man-in-the-middle attack on the priming
query, the only result for a validating resolver will be a denial of
service.

Section  5, add a reference to section 3.3, after "DNSSEC".

There is also a small contradiction between the abstract ("and the
necessary address information for reaching the root servers") and
section 4.1 ("There ___may be___ an Additional section with A and/or
AAAA RRSets").

Two personal questions (I cannot find a discussion on these two points
in the archive):

Section 4.1 "There may be an Additional section with A and/or AAAA
RRSets" There is no mention of what the resolver should do if this
section is missing. Sending a query XXX.root-servers.net/AAAA to the
same authoritative server used for the priming?

Section 4.2 "a resolver SHOULD consider the address information found
in the Additional section complete for any particular server that
appears at all" Why this rule? (Most root name servers, when the
advertised buffer is too small, sacrifice IPv6 addresses.)