Subject: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

From: Mark Andrews <[email-masked]>
Date: Tue, 3 Apr 2018 13:10:55 +1000

Do we really want to test for AD?  How many stub resolvers set DO or AD to elicit a AD response?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Tue, 3 Apr 2018 16:39:02 +1000

> On 3 Apr 2018, at 1:10 pm, Mark Andrews <[email-masked]> wrote:
> 

I’m not sure that we are on the same page here. The precondition is: "The AD bit is to be set in the response”  i.e. it is not a test on the query per se - it is a test on the response. Your comment appears to suggest that you believe that the text is asking for a test on the query. That is definitely not the intention of the text. i.e. it does not attempt to say what combination of flags in the query is used to signal that validation is to be applied (thats the role of RFC4035 and RFC6840), but the text is attempting to say “if the resolver has validated the response and is passing back a response that it is marking as being valid” then perform <actions>

I felt that saying that:

   o  The DNS response is DNSSEC validated

   o  the result of validation is "Secure"

   o  the AD bit is to be set in the response

would encompass this state. 

Is there a better way of saying this? Please suggest text if you believe that this could be stated more accurately.

thanks,

   Geoff

---

From: Mark Andrews <[email-masked]>
Date: Tue, 3 Apr 2018 17:38:15 +1000

AD is only set or potentially set in the response if DO or AD is set on the query.

The condition boils down to testing for AD or DO in the query because the answer needs to be secure and there can’t be a CNAME or DNAME pointing to it.  About the only way it to not have a AD would be for there to be a CNAME and the target be insecure based on the other conditions.

I would just remove the condition. 

-- 
Mark Andrews

> On 3 Apr 2018, at 16:39, Geoff Huston <[email-masked]> wrote:
> 
> 
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 3 Apr 2018 18:32:49 +1000

> On 3 Apr 2018, at 4:39 pm, Geoff Huston <[email-masked]> wrote:
> 
> 
> 

heh - the more I read the DNSSEC RFCs the more confused I get!

After further reading I now suspect that Mark is right, and the 
AD bit test is _not_ what is wanted.

Section 3.2.3 of RFC4035  reads

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic. 

So this text is saying that the AD bit is set if the resolver considers all
RRsets in the Answer section to be authentic. Fair enough.

But Section 5.8 of RFC 6840  reads:

5.8.  Setting the AD Bit on Replies

   Section 3.2.3 of [RFC4035] describes under which conditions a
   validating resolver should set or clear the AD bit in a response.  In
   order to interoperate with legacy stub resolvers and middleboxes that
   neither understand nor ignore the AD bit, validating resolvers SHOULD
   only set the AD bit when a response both meets the conditions listed
   in Section 3.2.3 of [RFC4035], and the request contained either a set
   DO bit or a set AD bit.

which appears to be saying that the AD bit is only set of the request contained
either a set DO ot a set AD bit.

What happens when neither DO nor AD is set in the request? 

Do you get a response that is authentic (but without any explicit signalling
in the response  that would indicate that authentication has occurred) or the
Servfail response in the case where authentication fails?

Or do you get a response that is not necessarily authenticated even though
the CD bit is not set?

If its the former then the AD bit may or may not be set on responses even though
they have been "DNSSEC validated”

---

From: Geoff Huston <[email-masked]>
Date: Tue, 3 Apr 2018 18:34:25 +1000

> On 3 Apr 2018, at 5:38 pm, Mark Andrews <[email-masked]> wrote:
> 

Thanks Mark. 

I had just posted a followup before seeing your response.

I’ll remove the condition then.

Geoff

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 03 Apr 2018 06:42:05 -0700

> I’ll remove the condition then.

Will you re-instate what Petr asked for, namely some wording that 
indicates that the resolver has to do DNSSEC validation on what it gets 
back from the authoritative server *regardless* of whether the 
originating client requests it? Without that, it is unclear what a 
resolver should do.

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Tue, 3 Apr 2018 16:08:46 +0000

> RRsets in the Answer section to be authentic. Fair enough.

More correctly, the bit is cleared if the resolver *doesn't* consider all
RRsets to be validly signed, but the distinction probably isn't that
important here.

> What happens when neither DO nor AD is set in the request? 

"dig +noends +noadflag" will produce such a query, if you want to try
it out.

> Servfail response in the case where authentication fails?

This. The resolver attempts validation and returns a plain-looking answer
if the response was valid or provably insecure, SERVFAIL if bogus.

> If its the former then the AD bit may or may not be set on responses even
> though they have been "DNSSEC validated”

That's correct.

(Also the AD flag can easily be turned on or off by an intermediate proxy,
so you should never rely on it for much of anything, really.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 3 Apr 2018 16:12:29 +0000

> "dig +noends +noadflag" will produce such a query, if you want to try

+noedns, rather.

The edns does not justify the means.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Apr 2018 12:21:28 -0400

> The edns does not justify the means.

Awghhhhh....
W

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

-- 
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: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2018 06:45:54 +1000

> On 3 Apr 2018, at 11:42 pm, Paul Hoffman <[email-masked]> wrote:
> 
> 
> Will you re-instate what Petr asked for, namely some wording that indicates that the resolver has to do DNSSEC validation on what it gets back from the authoritative server *regardless* of whether the originating client requests it? Without that, it is unclear what a resolver should do.
> 

Hi Paul,

(You should colour me as still confused!)

Is the wording “that the resolver has to do DNSSEC validation on what it gets back from the authoritative server *regardless* of whether the originating client requests it?” a clarification that updates the validation behaviours as specified in RFC4035 and RFC6840 as to when a security aware resolver performs validation? Or merely a clarification of the precondition in the context of the sentinel behaviour but of no wider import?

thanks,

   Geoff

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 03 Apr 2018 14:11:49 -0700

On 3 Apr 2018, at 13:45, Geoff Huston wrote:

> Is the wording “that the resolver has to do DNSSEC validation on 
> what it gets back from the authoritative server *regardless* of 
> whether the originating client requests it?” a clarification that 
> updates the validation behaviours as specified in RFC4035 and RFC6840 
> as to when a security aware resolver performs validation? Or merely a 
> clarification of the precondition in the context of the sentinel 
> behaviour but of no wider import?

The latter. Otherwise, someone reading the document might not understand 
that the response must be validated no matter what.

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2018 07:36:55 +1000

> On 4 Apr 2018, at 7:11 am, Paul Hoffman <[email-masked]> wrote:
> 
> The latter. Otherwise, someone reading the document might not understand that the response must be validated no matter what.

So you are saying that the document should revert to the wording:

   All of the following conditions must be met to trigger special
   processing inside resolver code:

   o  The DNS response is DNSSEC validated, regardless of whether
      DNSSSEC validation was requested.

   o  The result of validation is “Secure".

   o  The QTYPE is either A or AAAA (Query Type value 1 or 28).

   o  The OPCODE is QUERY.

   o  The leftmost label of the original QNAME (the name sent in the
      Question Section in the original query) is either "root-key-
      sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>”.

(I’ve split the initial condition into two explicit preconditions to be consistent with the rest of the enumerated list)

Any objections to this from the WG? I’ll wait for 24 hours and then post this wording as version 11 unless the WG says otherwise

Thanks,

  Geoff

---

From: Mark Andrews <[email-masked]>
Date: Wed, 4 Apr 2018 10:21:57 +1000

You are effectively saying that the resolver MUST ignore CD=1 for these queries.

> On 4 Apr 2018, at 7:36 am, Geoff Huston <[email-masked]> wrote:
> 
> 
>

---

From: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2018 10:28:39 +1000

I thought that if the query contained CD = 1 then the DNS response
would not be validated, and precondition 1 would not be met.

But I’m probably wrong, so could you please suggest wording here?

regards,

Geoff

> On 4 Apr 2018, at 10:21 am, Mark Andrews <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 4 Apr 2018 10:59:41 +1000

> On 4 Apr 2018, at 10:28 am, Geoff Huston <[email-masked]> wrote:
> 
> would not be validated,

This ONLY applies if the answer is NOT ALREADY CACHED.  If the answer
is already cached then CD=1 queries will get this processing as the
answer returned from the cache will be “secure” or “insecure” depending
on ealier validation.  If you don’t want CD=1 queries to get this processing
you need to explicitly exclude it.  You can’t depend on the answer NOT being
cached.

> and precondition 1 would not be met.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2018 11:17:10 +1000

> On 4 Apr 2018, at 10:59 am, Mark Andrews <[email-masked]> wrote:
> 
> 

Mark,

If I understand you correctly, then the preconditions need to include
an explicit provision that the CD bit is not set. 

Does the following wording work for you?

  o  The result of validation is “Secure”.

  o  The Checking Disabled (CD) bit in the query is not set.

  o  The OPCODE is QUERY.

regards,

   Geoff

---

From: Mark Andrews <[email-masked]>
Date: Wed, 4 Apr 2018 12:19:14 +1000

> On 4 Apr 2018, at 11:17 am, Geoff Huston <[email-masked]> wrote:
> 

No.  Below is self contradictory. Condition 1 requires that
CD=1 be turned into CD=0 and condition 3 requires that no special
processing happens for CD=1.

How CD is handled determines what you are testing when you have
resolvers in series.

Do you want CD=1 to disable special processing?
Do you want to only test the first validator?
Do you want to test the entire chain?
Do you want consistency?

All the scenarios need to be worked through remembering that there
is a cache that may be populated.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2018 14:30:20 +1000

> Do you want CD=1 to disable special processing?

yes

> Do you want to only test the first validator?

yes

> Do you want to test the entire chain?

no

> Do you want consistency?

err, umm - yes? (is this a trick question? :-) )

> is a cache that may be populated.

Mark, would it help if the phrase “regardless of whether DNSSSEC validation was requested.” 
was removed?

i.e.:

 o  The OPCODE is QUERY.

Geoff

---

From: Mark Andrews <[email-masked]>
Date: Wed, 4 Apr 2018 15:04:12 +1000

> On 4 Apr 2018, at 2:30 pm, Geoff Huston <[email-masked]> wrote:
> 
> 
> 
>> 

I think that is the way to go.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2018 15:12:29 +1000

> I think that is the way to go.

Mark, thanks for your patience with my evident cluelessness!

Geoff

---

From: Petr Špaček <[email-masked]>
Date: Wed, 4 Apr 2018 08:32:46 +0200

> Mark, thanks for your patience with my evident cluelessness!

The list of preconditions above is exactly what I meant but did not
manage to explain why it is necessary. Thank you very much for hashing
it out.

My apologies to dnsop and especially Geoff and Paul, I started this
avalanche and then did not follow up. Mea culpa!

-- 
Petr Špaček  @  CZ.NIC