Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 May 2010 09:54:58 -0400

Dear colleagues,

On Sat, Mar 27, 2010 at 07:04:22PM -0400, Samuel Weiler wrote:
> I'm hopeful that better text about controlling query floods will be  
> added soon.

The contribution of such text is the only thing standing in the way of
a WGLC on this document.  Anyone?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 14 May 2010 15:19:46 -0400

>a WGLC on this document.  Anyone?

Um.. the authors still haven't done anything to address/fix the text on the CD bit - go back to 3/24 for my diagram/discussion on why the current text is still inadequate.  I'll write text, but I want agreement as to the fix before that.  

It's really silly that this has taken more than 18 months (or pretty close by now) and still not done.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 May 2010 15:55:25 -0400

On Fri, May 14, 2010 at 03:19:46PM -0400, Michael StJohns wrote:

> Um.. the authors still haven't done anything to address/fix the text
> on the CD bit - go back to 3/24 for my diagram/discussion on why the
> current text is still inadequate.  I'll write text, but I want
> agreement as to the fix before that.

I just re-read that thread, and I went back and read the earlier
threads.  My impression was that several people agreed to text that
David suggested:
 
   When processing a request with the CD bit set, the resolver MUST set 
   the CD bit on its upstream queries.

   Furthermore, if the validating recursive resolver has a trust
   anchor covering a request, it SHOULD set the CD bit on its upstream
   query regardless of the CD bit setting of the request.

Right?  If so, it now belongs in 5.9 (because of changes since the -08
draft).  If not, please explain why not.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 14 May 2010 20:41:31 -0400

For the rest of you joining us late, this discussion does not assume that there is a single validating resolver between the querier and the authoritative servers (which is the most typical implementation).  It's an unusual architecture, but there are situations where having at least two validating resolvers in the path may happen.  Because of this, a validating resolver can't assume its next query will go directly to the authoritative server and may need to twiddle with the CD bit in the Upstream query.

>draft).  If not, please explain why not.

Its really much more complex than the above.  Sadly.

-08 is where the above text comment was made (and never acted upon),  -11 inserted instead:

 When processing a request with the CD bit set, a resolver SHOULD  

>> the SHOULD mirrors the "SHOULD" in 4035 3.2.2, but probably should be a MUST.  The language in 3.2.2 is pretty clear what the intent of the CD bit is - resolver is not responsible for validation.  Otherwise, just add something like "An intermediate resolver MAY implement an option to be configured to ignore the CD bit in queries, in which case it behaves exactly as if the CD bit were not set.  The option MUST default to non-ignore" to the CD section

   attempt to return all responsive data, even data that has failed

   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver

   processing a request with the CD bit set to set the CD bit on its

   upstream queries.

   The guidance in RFC4035 is ambiguous about what to do when a cached

   response was obtained with the CD bit not set. 

>> its also ambiguous what to do when a cached response was obtained with the CD bit set and the query is for non-CD data.  E.g. do you not cache the unvalidated data?

 In the typical case,

   no new query is required, nor does the cache need to track the state

   of the CD bit used to make a given query.  

>> This sentence appears to be wrong, but for the wrong reason.  You need to track the CD bit not because of the CD bit queries but because of the non-CD bit queries.  See below and my diagram.

The problem arises when

   the cached response is a server failure (RCODE 2), which may indicate

   that the requested data failed DNSSEC validation at an upstream

   validating resolver.  (RFC2308 permits caching of server failures for

   up to five minutes.)  In these cases, a new query with the CD bit set

   is required.

>> the language David proposed was wrong, the above is correct.

   For efficiency, a validator may wish to set the CD bit on all

   upstream queries when it has a trust anchor at or above the QNAME

   (and thus can reasonably expect to be able to validate the response).

>> this doesn't appear to be an efficiency issue.  A resolver SHOULD/MUST set the CD bit on all TA covered upstream queries, otherwise it's not getting the data to do its job.  Sam made a counter argument in the 3/30 exchange which I believe is contrived, but at least marginally possible.  The text for his covering the implementation of his argument would have this be something like:  "The resolver MAY implement an option to to clear the CD bit on any or all  TA-coverd non-CD bit queries to take advantage of validation at resolver closer to the authoritative servers"   To be blunt, I think this is a bad idea - if you want to do this, simply remove your local TAs.  
The -11 text ignores a number of subcases.  See my diagram of 3/24 but basically

if query CD bit is set  
if response is cached  
if SERVFAIL is cached  
Set CD bit upstream and query 
Else  
Return cached 
else // response not cached  
Set CD bit upstream and query 
else // query CD bit clear  
if response is cached  
if cached response had CD bit set  
if resolver has covering trust anchor  
run validation against cached and return 
else // resolver can't validate locally and data wasn't validated upstream  
clear CD bit and query 
else // prev data was validated upstream if at all  
return cached data 
else // response not cached  
if resolver has covering trust anchor  
set CD bit and query then validate locally 
else  
clear CD bit query and return

While looking at this, I realized that it may be possible to "poison" the cache of a non-validating (but DNSSEC away) intermediate resolver by passing it a CD bit set query.  Later queries to that same data - unless the resolver realizes it needs to requery - may get the non-validated data and I can't see any text either in 4035 or -11 that would prevent this.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 May 2010 10:38:12 -0400

On Fri, May 14, 2010 at 08:41:31PM -0400, Michael StJohns wrote:
> the SHOULD mirrors the "SHOULD" in 4035 3.2.2, but probably should
> be a MUST.  

More than one person has responded to your suggestion here by saying
it's too prescriptive.  I'm not entirely sure I agree, but to the
extent there's been responses, most of them have disagreed with MUST.

> The language in 3.2.2 is pretty clear what the intent of
> the CD bit is - resolver is not responsible for validation.

My reading is that the CD bit is not saying, "You're not responsible,"
but rather, "Give me everything."  

> Otherwise, just add something like "An intermediate resolver MAY
> implement an option to be configured to ignore the CD bit in
> queries, in which case it behaves exactly as if the CD bit were not
> set.  The option MUST default to non-ignore" to the CD section

I sort of hate the idea of "disable checking disabled", which I think
is what you're suggesting there.

> this doesn't appear to be an efficiency issue.  A resolver
> SHOULD/MUST set the CD bit on all TA covered upstream queries,
> otherwise it's not getting the data to do its job.  Sam made a
> counter argument in the 3/30 exchange which I believe is contrived,
> but at least marginally possible.  The text for his covering the
> implementation of his argument would have this be something like:
> "The resolver MAY implement an option to to clear the CD bit on any
> or all TA-coverd non-CD bit queries to take advantage of validation
> at resolver closer to the authoritative servers" To be blunt, I
> think this is a bad idea - if you want to do this, simply remove
> your local TAs.

I don't think that was what he was saying, but I'll defer to him.  I
have the impression that you're making this slightly more complicated
than it really is.  In particular, I looked at your diagram, but I
still don't get how it entails the strong requirements you seem to
want.  I'm also not entirely sure what text you want in the document
-- if you could supply actual text for evaluation, that would help.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 May 2010 11:23:23 -0400

On Sat, May 15, 2010 at 03:19:38PM +0100, George Barwood wrote:
> The objectives are 
> (a) As much validation as possible is performed when answering CD=0 queries.

By whom?  Why is this a goal?

> (b) Validation failures are to be avoided when answering CD=1 queries.

Why are they to be avoided?  Obviously, we want _false_ validation
failures not to happen.  But we always want that.  And validation
failures by whom?  Presumably by the querying client?

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 May 2010 15:48:19 -0400

Let me hit this one first and then go back and deal with your other email.

>By whom?  Why is this a goal?

I assume George meant "as much validation as possible is performed [by an intermediate validating resolver] etc..."   Are you saying this isn't a goal of the general DNSSEC design?  If you believe it isn't then we're really on separate pages.

>failures by whom?  Presumably by the querying client?

Again, George meant by the intermediate resolver.  CD stands for "Checking Disabled" and is a request to the upstream resolver to pass through raw data - or that how its always been described to me.  E.g. don't attempt to do validation, just pretend you know nothing at all about DNSSEC and give me the raw data as if I had asked the upstream server myself.    

So I wouldn't phrase it as "have the intermediate resolver avoid validation failure" so much as "have the intermediate resolver get the hell out of my way and just let me do my own validation if I so choose".

I state forcefully that it is a REQUIREMENT that if the CD bit is set, absent any [stupid] policy by a containing organization, that an end entity be able to get to raw data if it asks for it.  This may be the only thing that saves us when (note that I do not say if) some upstream validating resolver manages to screw up the trust anchor (or the signing authority screws up the signatures) for .COM and makes the entire .COM tree disappear to those stuck behind validating resolvers.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 May 2010 16:51:57 -0400

On Mon, May 17, 2010 at 03:48:19PM -0400, Michael StJohns wrote:

> I assume George meant "as much validation as possible is performed
> [by an intermediate validating resolver] etc..."  Are you saying
> this isn't a goal of the general DNSSEC design?  If you believe it
> isn't then we're really on separate pages.

But that's not consistent with what you go on to say:

> So I wouldn't phrase it as "have the intermediate resolver avoid
> validation failure" so much as "have the intermediate resolver get
> the hell out of my way and just let me do my own validation if I so
> choose".
> 
> I state forcefully that it is a REQUIREMENT that if the CD bit is
> set, absent any [stupid] policy by a containing organization, that
> an end entity be able to get to raw data if it asks for it.  This

If the goal of CD is in fact, "Give me everything, even if you have to
go get it to see whether it's out there," then I agree that this is a
clarification we need to make; but it does not mean "as much
validation as possible".  It means, instead, exactly the validation
that the requesting client can do and nothing else.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 May 2010 17:40:09 -0400

>extent there's been responses, most of them have disagreed with MUST.

See my email response to your response to George's later email.  Having this as a MUST is a safety valve for when either the trust anchor or signatures get screwed up and you absolutely need to bypass DNSSEC validation.  Without this, we're going to be captives of our ISP's query redirection and misconfigurations. 

>but rather, "Give me everything."  

I'll go along with this.

>is what you're suggesting there.

I hate this too, but too many counter-arguments to this discussion have stated that whether the CD bit is set in the upstream from an intermediate resolver is a local policy (e.g. a SHOULD vs a MUST).  I would argue then that whether or not you do validation for CD-bit set queries from a client should also be a local policy.  E.g. either both or none.   Since you don't know what's upstream of you - e.g. authoritative vs intermediate - you really need to do something consistent.

>-- if you could supply actual text for evaluation, that would help.

I did - its the if/then/else text in my earlier message.  If there's a branch that you think is incorrect or not necessary, please point me to it and explain why I'm wrong.

Basically, if I do a CD bit set query at the client, I want to be a) able to use the local intermediate resolver caches (because those are the ones I know about through auto configuration/DHCP), b) be assured that the intermediate resolver cache is passing through the original data from the authoritative servers.

At the first intermediate resolver, I don't necessarily know that the upstream query will get directly to the authoritative server - it may get intercepted and redirected to another, higher level resolver  (or the first intermediate resolver may have a configuration which directs certain subsets of queries to a non-authoritative server) which may or may not do validation (also something the first intermediate resolver may not be able to detect).    

This system should work - or be designed to work - regardless of the number of intermediate resolvers in the system.  The design assumptions of a single intermediate resolver between the client and the authoritative server are not universally valid.

Interestingly, the comment in -11 that says you don't have to track CD bit set on cached data is a little bit of sophistry -I'm still not convinced of this and I think it may be wrong - see below.

So how about this for text:

-11 section  3.1.1  and or 5.9 --- this may reflect current implementation practice, but I couldn't find this called out anywhere.  

"Security aware intermediate resolvers MUST set the CD bit on any upstream query for which they have a covering trust anchor (TA).

Security aware intermediate resolvers SHOULD cache data returned from an upstream (server side) query which had the CD bit set.  If the downstream (client side) query also has the CD bit set, the resolver MAY defer validation of this data (assuming a covering TA) until a later non-CD bit query for the same data, but MUST mark the cached data as non-validated until local validation actually occurs.

Security aware intermediate resolvers SHOULD cache SERVFAIL responses returned from an upstream query. They MUST cache the state of the CD bit in all upstream queries as well.  If a security aware intermediate resolvers receives a query for data which has a SERVFAIL cached, but with the CD bit set, the resolver MUST set the CD bit on the upstream query and cache BOTH the SERVFAIL and the returned data.  Data in cache with the CD bit set which has not been locally validated MUST NOT be returned to a non-CD query.   If the cached data has the CD bit set it may be returned to a CD query, and if a SERVFAIL is cached it may be returned to a non-CD query, otherwise this should be treated as a cache miss and the query repeated upstream."

The above is closer, but may still be missing some corner cases.     

For the first paragraph, simply delete the TA if you don't want to force the setting of the CD bit.  There is no way - programatically or protocol wise to determine if an upstream resolver can do validation over this query so making this a SHOULD makes no sense whatsoever.  

The second paragraph covers whether or not unvalidated data is cached and how to treat it.  I couldn't find any discussion of tracking validation status in cache in either 4035 or -11, but it maybe somewhere else.  If you have a covering TA and enough cycles it may be reasonable to do the validation at the same time even if the downstream (client) query has the CD bit set rather than having to track validation status.  But from a resource POV, I'd rather delay it until someone actually asks to have it done (by not setting the CD bit).

 The last paragraph deals with an aware resolver which doesn't have a TA covering a CD query from a client.  The same upstream query may result either in data (if the client sent a CD query upstream) or the SERVFAIL if it didn't.    I think it also implies you have to track whether or not you did an upstream query with the CD bit if you want to serve data from cache.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 May 2010 17:45:38 -0400

>But that's not consistent with what you go on to say:

Sorry - you're confusing me with George.  I want - "give me all" - George said "as much as possible".

>go get it to see whether it's out there," 

I think that's exactly what it is.

>then I agree that this is a

And I agree that what I said wasn't "as much as possible".. :-)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 May 2010 18:00:22 -0400

> Sorry - you're confusing me with George.  I want - "give me all" - George said "as much as possible".

I'm not confusing you.  You appeared to be suggesting that as much
validation as possible is supposed to be performed by someone as a
goal of the general DNSSEC design (in your rhetorical question,
reproduced above).  I was just pointing out that that's not consistent
with what you're claiming the CD bit is for.  If CD means what I think
you are saying it means (and I have some sympathy with that
interpretation), then it cannot possibly be a design goal in general
that we get as much validation as possible.  And indeed, my reading of
4035 suggests that a security-aware validating recursive name server
needn't do validation if it gets a query with CD set.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 17 May 2010 20:53:30 -0400

At 06:00 PM 5/17/2010, Andrew Sullivan wrote:
>reproduced above).

Heh... you're still misreading this - a bunch of cross references I think.  I was asking simply if you disagreed with George's statement that this was a goal, not whether or not the goal trumped the setting of the CD bit.

George said that one general goal of DNSSEC was to do as much validation as possible at intermediate resolvers  - that's correct and I think you agree that was a goal in the design..  But setting the CD bit is the escape clause.   Which discussion was in a separate paragraph.

So two separate items:

1) DNSSEC goal is to do as much validation as possible in intermediate resolvers.  (I don't necessarily think this was a good goal by the way).
2) If the CD bit is set, intermediate resolvers should get out of the way and just pass through the unvalidated data.

>  I was just pointing out that that's not consistent
>that we get as much validation as possible.  

Yes.  Agreed.  Done.
Again - you're conflating two different discussions and responses into one item.  So I hopefully think were past that now?

>And indeed, my reading of

And its not just "Suggests"  From 4035:

A security-aware resolver MAY set a query's CD bit in order to
   indicate that the resolver takes responsibility for performing
   whatever authentication its local policy requires on the RRsets in
   the response. 

>From 4033:  (emphasis mine)  

Thus, a
   security-aware resolver that is part of a security-aware recursive
   name server will have to pay careful attention to the DNSSEC
   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
   blocking valid signatures from getting through to other
   security-aware resolvers that are clients of this recursive name
   server.

[Side note - the ref above is wrong, the CD bit isn't mentioned in 4034]

So with respect to the answer to the querier, someone receiving a CD bit set query is not responsible for returning post-validation data.  HOWEVER, this doesn't talk about what has to happen locally with respect to caching of the CD bit set data and whether or not validation need be done before caching, marking etc.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 19 May 2010 11:39:33 -0400

I wanted to make sure this didn't get lost in the discussion.  Here's my proposal for a replacement to the text in 5.9 in -11.  This is slightly edited from the previous message.

"Security aware intermediate resolvers MUST set the CD bit on any upstream query for which they have a covering trust anchor (TA) or for which the downstream query has the CD bit set."

Security aware intermediate resolvers SHOULD cache SERVFAIL responses returned from an upstream query. They MUST cache the state of the CD bit in all upstream queries as well.  If a security aware intermediate resolver receives a  CD bit set query for data which has a SERVFAIL cached,  the resolver MUST set the CD bit on the upstream query and SHOULD cache BOTH the SERVFAIL and the data returned on the CD bit set upstream query.  

Data in cache with the CD bit set which has not been locally validated MUST NOT be returned to a non-CD query.   If the cached data has the CD bit set it may be returned to a CD bit set query, if a SERVFAIL is cached it may be returned to a non-CD query, and if the cached data has the CD bit set, and there is a covering TA it may be locally validated and returned.  Otherwise this should be treated as a cache miss and the query repeated upstream."

The second paragraph covers whether or not unvalidated data is cached and how to treat it.  I couldn't find any discussion of tracking validation status in cache in either 4035 or -11, but  maybe its somewhere else.  If you have a covering TA and enough cycles it may be reasonable to do the validation at the same time [you query] even if the downstream (client) query has the CD bit set rather than having to track validation status.  But from a resource POV, I'd rather delay it until someone actually asks to have it done (by not setting the CD bit).

The difference between the MUSTs and SHOULDs above are that the MUSTs are protocol related where the SHOULDs are implementation related.  If you don't do a SHOULD (e.g. don't implement cache for both SERVFAIL and CD-bit set data, but only one or the other) you can still do your job by requerying upstream with the appropriate bits set.  In the MUST case above, I can't figure out any programmatic way of deciding when to set the CD bit if this a "SHOULD".    If you believe this is a SHOULD, then you need text describing the specific configuration option that applies so that we can get consistent behavior out of the DNS.  The MUST NOT case above is a security requirement - obviously, unless asked to do so specifically (via the CD bit) you shouldn't return non-validated data to a query if you've got a covering TA.

Finally, deleting "intermediate" from before "resolver" may be appropriate because looking at this, it's probably appropriate behavior for a caching validating stub resolver.  Different applications will request different behavior out of the local stub resolver.

Mike

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 22 May 2010 19:59:19 -0400 (EDT)

Thank you for this summary.

On Sat, 15 May 2010, George Barwood wrote:

> (c) The number of upstream queries should be minimised subject to (a) and (b) being satisfied.

I concur with all of the above.  (Strange wording of B aside, I'm 
encouraged that we all seem to agree on what's desired when CD=1.)

I think the disconnect between me and Mike is over point A.  Indeed, I 
want to be able to use a local resolver with a small set of trust 
anchors (for islands or high-value zones) while having an "upstream" 
resolver do the heavy lifting of maintaining a bigger set of trust 
anchors.  So I don't want my setting of a trust anchor to immediately 
cause CD to be set.  Maybe we can find a way to make that optional.

The text in -11 also makes the bold new leap of assuming that "if you 
got a positive answer with CD=0, you don't have to query again with 
CD=1, even if the incoming query is CD=1".  That's in the service of C 
above.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 22 May 2010 20:09:01 -0400 (EDT)

Thanks to all for your efforts to move this along.

On Wed, 19 May 2010, Michael StJohns wrote:

> "Security aware intermediate resolvers MUST set the CD bit on any 
> upstream query for which they have a covering trust anchor (TA) or 
> for which the downstream query has the CD bit set."
...
> For the first paragraph, simply delete the TA if you don't want to 
> force the setting of the CD bit.  There is no way - programatically 
> or protocol wise to determine if an upstream resolver can do 
> validation over this query so making this a SHOULD makes no sense 
> whatsoever.

So we disagree about the covering trust anchor.

Moving on: I concur that NEW queries needed to respond to CD=1 should 
be made with CD=1. As in my last message, the text in -11 assumes that 
cached postive answers are good enough, even if made with CD=0, so a 
new query may not always be needed.

> The second paragraph covers whether or not unvalidated data is 
> cached and how to treat it. ...

This all sounds unnecessarily prescriptive.  But, indeed, the text in 
-11 may not be clear enough.  Is there a more concise way to say 
what's needed here?

-- Sam

---

From: Michael StJohns <[email-masked]>
Date: Sun, 23 May 2010 01:25:29 -0400

At 08:09 PM 5/22/2010, Samuel Weiler wrote:
>>The second paragraph covers whether or not unvalidated data is cached and how to treat it. ...
>
>This all sounds unnecessarily prescriptive.  But, indeed, the text in -11 may not be clear enough.  Is there a more concise way to say what's needed here?

This is reminiscent of one of my encounters with a car salesman - he invited me to bid against myself by telling me my offer was too low and requested another bid..   

Let me turn it around.  

What of the text do you find "overly prescriptive" and why?  How would you change it and why?    And while "conciseness" is a desired trait, correctness is even more desirable. I belive the text is correct and complete.  Do you have a different take on it?  Is it wrong or does it miss key conditions?

If you believe the text is incorrect, I'm happen to take suggestions for amending it.  Or to even address claims of incorrectness.

The -11 text is incomplete for the reasons stated elsewhere.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 23 May 2010 01:25:22 -0400

At 07:59 PM 5/22/2010, Samuel Weiler wrote:
>I concur with all of the above.  (Strange wording of B aside, I'm encouraged that we all seem to agree on what's desired when CD=1.)
>
>I think the disconnect between me and Mike is over point A.  Indeed, I want to be able to use a local resolver with a small set of trust anchors (for islands or high-value zones) while having an "upstream" resolver do the heavy lifting of maintaining a bigger set of trust anchors.  So I don't want my setting of a trust anchor to immediately cause CD to be set.  Maybe we can find a way to make that optional.

Hi Sam - 

You've got two hats here - one as document editor and one as individual contributor.  I assume the above is  offered as an IC and not the document editor?

In any event, over the last few years you've objected to this repeatedly and I've asked repeatedly for analysis from you and others why setting the CD bit if you have a covering TA should be optional especially given the text in section 6 of 4033.

So instead, let me offer my own analysis.  Feel free to dispute it, but let's get this away from the realm of "don't like" into the realm of "here's what works and why".

Assume that we have a non-CD bit query coming to the local resolver for something under "foo.com". Assume the local resolver has a trust point and trust anchor for "foo.com".  Let's assume that we don't set the CD bit on the upstream - for whatever reason (Call it the Sam implementation).  Let's finally assume that the local resolver does validation on everything covered by its trust anchors (which seems to be the defined approach if you have a TA covering the query)

1) Assume there is an uptream resolver with a trust point also for foo.com.

   a) Condition:  Both local and upstream have the same trust anchor
       Result:  No difference than had you set the CD bit and done local validation

   b) Condition: local has a good (current, valid) trust anchor, upstream had a bad (old, wrong) trust anchor
       Result:  Upstream returns SERVFAIL in error, client can't connect

   c) Condition: upstream has a good trust anchor, local has a bad trust anchor
       Result: local returns SERVFAIL in error, client can't connect.

   d) Condition: both have bad trust anchors for foo.com
       Result: upstream returns SERVFAIL, but so would local validation.

2) Assume the upstream resolver has a trust point for .com instead of for foo.com
   
    a) Condition:  upstream resolver .com TA chains to the same foo.com key as the local trust anchor.
        Result:  no difference than had you done local validation

    b) Condition:  upstream resolver .com TA chains to old DS for foo.com, or has other validation failures in chaining; local has good trust anchor
        Result:  SERVFAIL in error from the upstream
    
    c) Condition: local has old trust anchor, upstream chains to valid key and validates
        Result: SERVFAIL in error from the local resolver

    d) Condition: both have bad or unchainable trust anchors
         Result: SERVFAIL, but no different than if you'd done local validation

 From your comments I'm getting that you seem to some how be implying that its possible for the local resolver to get a trust anchor that will accept invalid data. and that you think the upstream resolver can protect against that.  I'm not sure how that happens. Could you care to elaborate? 

Have I missed the case or cases you care about?  

If you have an assumption that the local resolver some how knows what trust anchors the upstream resolvers has, you need to explain how that could happen (e.g. configuration, discovery through protocol) and why that changes my analysis.  

If you are concerned that an upstream resolver might get a TA revocation faster than your local resolver - what would be the impact?  And what would be the impact of the local resolver getting the revocation before the upstream resolver?  Which is more manageable from the local resolver's point of view?  Which gives the more predictable result?

Finally,   if after all of the above you still think that not setting the CD bit in an upstream query covered by a local TA is optional, you need to precisely define (so it can be implemented) the situations under which the CD bit is cleared.  If its cleared all the time, you need to explain why simply removing the local resolvers TA isn't the appropriate action.  If its cleared only part of the time, you need to explain how the resolver might choose when to set it.

Seriously, if you have a trust anchor that covers the query, set the CD bit in the upstream query and do local validation.  If you don't set the CD bit all you're doing is multiplying the possible errors.   1b, and 2b are errors that need not happen.

>The text in -11 also makes the bold new leap of assuming that "if you got a positive answer with CD=0, you don't have to query again with CD=1, even if the incoming query is CD=1".  That's in the service of C above.

I agree with this.  But, you still don't address the "if you get a positive answer with CD=1, you should requery again if you get an incoming query of CD=0" issue.  That's also in service of c (and a) above.  If you query upstream with the CD bit set because the downstream had the CD bit set (per 4035), then you have in cache possibly unvalidated data.  If you have no local trust anchor for that cached data, and you then get a CD=0 query you can't return the data in cache because of the lack of validation.  Or do you disagree with that statement?

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 23 May 2010 17:31:31 -0400

Comments in line.    The key question is "why would I trust the upstream resolver more than I would trust my local resolver?"   I haven't yet heard an answer to this that I find valid.

At 03:20 PM 5/23/2010, George Barwood wrote:

>----- Original Message ----- 
>From: "Michael StJohns" <[email-masked]>
>To: "Samuel Weiler" <[email-masked]>; "George Barwood" <[email-masked]>
>Cc: "Andrew Sullivan" <[email-masked]>; <[email-masked]>
>Sent: Sunday, May 23, 2010 6:25 AM
>Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data
>
>
>In my earlier post on this ( http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01289.html ), I stated
>
>   But this is a grey area - it's to some extent a matter of local policy whether 
>   CD=1 is set on upstream queries. CD=0/1 is a boolean flag, so nuances canot be expressed.
>   I don't think the existence of a local trust anchor is decisive : an upstream cache
>   may have a more dependable ( better validated / closer ) trust anchor.
>   However, I think the default should be that validation is performed unless
>   CD=1 has been specified by the final client, or some specific configuration is in effect.
>
>To expand on this : trust anchors have to be acquired, and may be forged.

Yes but:  1) Why would you think that an upstream resolver couldn't also have its TA forged?  2) Why would you install locally a forged trust anchor?   3) Why would you repose more trust in the upstream resolver than the local resolver and still install local TAs?

>So in your example below, if the local trust anchor for foo.com has been forged
>on the local resolver, but is valid on the upstream, setting CD=1 allows bogus data
>through that would otherwise be caught.

But also in the example, if you have a forged local trust anchor, all the non-forged data gets dropped at the local resolver - cases 1c and 2c.  So the forged trust anchor turns into somewhat of a denial of service in the normal case.

So how much of a risk is this extremely contrived case?   Let me be blunt - I can't see it as a risk that matters.  If your local resolver is compromised, it can tell you whatever it wants regardless of TAs and validation settings.   This protocol behavior is not meant to deal with the general issue of compromise or misconfiguration of a resolver - only with the normal, defaul, expected behavior.  

>But the common case is where the local resolver has a trust anchor for <root> and the
>upstream resolver has a trust anchor for the company domain. In this case the local
>resolver should not set CD=1 on it's upstream, as configuration on the upstream resolver
>indicates that the parent zones of the company zone are not fully trusted.

This really isn't a common case AFAIK - the more common case is the upstream encloses the local, not the other way around.  The correct way to deal with this - if this is a company specific local resolver - is to install a company specific TA in the local resolver.  Yes, there are lots of ways for a resolver system manager to screw up, but this one is just laughable.

As I've mentioned before several times - there is no way - absent specific configuration - that a resolver knows whether or not there is an upstream validating resolver.  If this is the case you're concerned about, you have two choices - either a) delete the <root> TA locally and ensure that all queries are proxied to an upstream resolver with <root> or b) implement an option to carve a hole in your trust anchor coverage (e.g. pass all <company>.<root> queries upstream without CD, even though you have a TA for <root>.   Implementations mostly support a), I'm willing to have someone else write the language to support b) even though I think it will rarely if ever be turned on.

>So the "safest" way to proceed is to not set CD=1 on upstream queries when answering CD=0 queries,
>and this SHOULD therefore be the default behavior IMO. 

This is a conclusion - and one I consider false, possibly based on a definition of "safe" foreign to me.   The only time this gets you "protected" is if a) someone's hacked the local TA store and installed fake "good" keys (or the manager was too incompetent to use good security practices), and b) if the upstream exists and c) the upstream wasn't also hacked and d) someone tried to give you forged data.   

Not setting CD on the upstream means that validation failures due to stupidity on the part of a resolver that you don't manage (the upstream resolver) can prevent you from resolving and validating data for which you have the appropriate trust anchor.  Shall we talk for a while about the .gov signature issues for example?

But seriously, if I can get the fake keys installed in the local TA store, why couldn't I just twiddle with other behavior?  Like whether or not to set the CD bit in the upstream for a specific set of queries?  

>It would be ok to manually override this for performance reasons ( one can expect CD=1 queries
>to be faster ), and it could be a flag that is specified when a trust anchor is configured in the local resolver.

See above - not just a flag, but a carve out from setting the CD bit (not clearing it as you propose).  If you believe the upstream has the same TA as yours and you're willing to have the upstream do the validation, simply delete your local TA.  If you believe the upstream has a more specific TA than yours (because you were told out of band that was so), and you want it to be the source of validation for that TA - which you hopefully know - then configure a CD exception that has to be a proper enclosed TA of one of your local TAs.   

(Hmm... so what happens when the upstream - without warning - deletes that enclosing TA?)

>Still, it would also be ok to say it's purely a matter of local policy, and make no specific recommendation
>as to the default behavior. I don't have a strong view on that.

If its a matter of local policy, you need to describe a behavior that's a default and not depend on X number of vendors to do it all the same way through guess work.    Saying its local policy without defining a default is hand-waving of the worst kind.

>Regards,
>George

---

From: Michael StJohns <[email-masked]>
Date: Sun, 23 May 2010 18:53:03 -0400

At 05:58 PM 5/23/2010, George Barwood wrote:

>To: "George Barwood" <[email-masked]>; "Samuel Weiler" <[email-masked]>
>Sent: Sunday, May 23, 2010 10:31 PM
>Answer : you don't trust either - you hope that one of them has a non-bogus trust anchor.

"hope" is not really a security attribute.... 

*sigh*  OK - we're really out in left field here.  And I don't mean to pick on you, but your logic chain is broken.

1) If EITHER of them has a bogus trust anchor - forged or otherwise, the client gets a SERVFAIL, even if one of them has a non-bogus trust anchor.  So hoping that one of them has a non-bogus trust anchor is really not all that useful.  BOTH need a non-bogus TA to be useful.

2) If you don't trust either, then create a client set of TAs and have your client set the CD on all of its upstream queries including the initial one to the local resolver.

>Another point ( that occurred to me after my previous post ) is that even if you have a trust anchor ( say for <root> ), there may be a break in the authentication chain, but the upstream may have a trust anchor that cures that.

No, it doesn't.  If you have a break in the local, then you get a SERVFAIL from the local, regardless of what you get from the upstream.

>Some inline answers below, although maybe the discussion is now losing focus I think.
>
>George
>
>> 
>
>Hmm.. I don't immediately follow here. If you set CD=1 on the upstream query, and the local trust anchor is bogus, then the end client can get bogus reponses,  that would otherwise potentially be caught by the upstream resolver.

Your comments were about setting requiring CD=0 on upstream queries for CD=0 downstream queries even if you have a local TA covering the query.  If you set CD=0 on the upstream query and the upstream has a bogus chain or  TA, you get a SERVFAIL which the local then returns to the client.  If the upstream has a valid TA or chain and your local has a bogus TA, the local gets validated data from the upstream, but then attempts its own validation and returns SERVFAIL to the client.

There is no way for good (validated) data to get to the client unless BOTH have the same good TA or TA chains (for a local CD=0 to the upstream query where the local has a TA covering the query).

>There is no quantitative answer to this question, but it's a non-zero risk.

Yup, but the risk is an included risk in the general concept of compromise or misconfiguration - its no greater than that risk and that risk has more possible impacts.  "fixing" this issue the way you seem to want to, doesn't really prevent other misconfiguration or compromise issues - and therefore doesn't actually fix anything.

>Another aspect is that if CD=1 is reserved for "emergency" use, queries to a site resolver with CD=1 set
>can trigger warnings to administrators that all may not be well. If using CD=1 on the upstream is standard,
>there is no way to enforce authentication at the site level, other than disabling CD=1 entirely.

Oh b*******t.  Please re-read section 6 of 4033.  The CD bit is NOT for emergency use - it is for a resolver to say to the upstream folks - get the hell out of my way and give me the raw data.   

I assume you mean"name validation" when you say "authentication"?  If you're thinking that its more (e.g. authenticating my login to a machine or some such)  then you're going to need to make a longer explanation.

To put paid to this argument - intermediate resolvers are all about efficiency, and not so much about control.  Given that an end system can completely bypass local resolvers by doing the queries themselves, there isn't any way to actually "disable CD=1" entirely.  Yes, you can firewall against this (*sigh*) but then I would hope you'd trust your local resolver (inside the firewall) to do the right thing rather than just praying the upstream resolver (outside the firewall) had a clue.

>Depends on the mechanism by which trust anchors are distributed. But any distribution method has potential weaknesses.

So does any server.  What you're trying to do is put a 1 ft thick steel vault door on a 2x4 and drywall closet.  It might look shiny and secure, but it provides no additional protection over that wooden door with a lock that was there. E.g the same amount of force will still get you in the closet.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 23 May 2010 19:33:15 -0400

On Sun, May 23, 2010 at 6:53 PM, Michael StJohns <[email-masked]>wrote:

> ...
> There is no way for good (validated) data to get to the client unless BOTH
> have the same good TA or TA chains (for a local CD=0 to the upstream query
> where the local has a TA covering the query).

Why couldn't they have different TA's if the data is all signed by two
algorithms/keys for example?

Donald

---

From: Michael StJohns <[email-masked]>
Date: Sun, 23 May 2010 21:44:26 -0400

At 07:33 PM 5/23/2010, Donald Eastlake wrote:
>On Sun, May 23, 2010 at 6:53 PM, Michael StJohns <<mailto:[email-masked]>[email-masked]> wrote:
>...
>Why couldn't they have different TA's if the data is all signed by two algorithms/keys for example?
> 
>...
>
>
>Donald 

Sorry - trying to keep the discussion somewhat simple.  There are a lot of iterations down the decision tree that really don't change things.  Unless you can see one?

While you're correct that each could have different (actually disjoint) TAs, in practice, they should be getting the TA sets from the same place.  I guess its possible that different resolvers only cared about  (implemented support for) one set of signature algorithms, but in practice - we're currently only using the one.  But its fair to design for what's in the protocol.

What's more probable is that the two different entities have different sets of Good, Bad or Mixed TAs within the trust point - due to differences when each picks up the TP (trust point) changes (e.g. 5011's 30day window ) or is otherwise configured.  The ZSKs are probably the same, but the KSKs referenced by each TP aren't necessarily the same.  

I don't think it changes the analysis much if at all.  You still need both the local and upstream resolvers to have non-bogus trust anchors at the trust point so they'll pass the data through. Contextually, that was the point of that specific set of paragraphs.   If either or both have no non-bogus TAs you end up with a SERVFAIL. 

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 24 May 2010 13:14:02 -0400

At 01:04 AM 5/24/2010, George Barwood wrote:

I was responding to your "let's use CD=0", but if you want to talk about "CD=1" so be it.

>Nope. If the local resolver has a bogus trust anchor (i.e. an attacker has managed to insert this anchor)
>and it sends a CD=1 query to it's upstream, then the local resolver can get RC=Ok, but the data is
>actually the attackers data. This attack is prevented by using CD=0 on the upstream query ( unless
>of course the attacker has also managed to insert the bogus anchor in the upstream resolver ).

The attack is prevented - IN THIS ONE SPECIFIC CASE - if and only if ALL of these conditions are true:
a) The local resolver has a maliciously bogus TA that validates the data
b) The local resolver doesn't set the CD bit in the upstream query
c) An upstream resolver actually exists
d) The upstream resolver was actually asked to resolve this query
e) The upstream resolver didn't also have the same bogus TA
f) The bogus data wasn't inserted below the upstream resolver  - the local resolver didn't get the bogus answer first from someone closer

The key point above is (e) - if my local resolver has a bogus trust anchor for data, the attacker simply needs to get the response to me before the upstream resolver.  So doing it your way doesn't actually provide any additional protection and doesn't act as suspenders to the local DNSSEC belt.

Still not sure why an attacker would do (a) and not mess with the local resolver in other ways.

>You have not appreciated that trust is not an absolute. Practical security proceeds by having multiple
>layers, none of which are completely secure, but each layer gives an additional obstacle for an attacker to overcome.

I appreciate this.  Been doing it for quite a long while.  But you're treating the upstream resolver as another "firewall" with an absolute application of its rules. As I've said multiple times before, you can't make this assumption.  Absent specific configuration, the local resolver has NO idea of whether or not there is an upstream validating resolver and whether further validation will be done.  It can't actually discover this, because queries can be redirected at layer 3 for example.   So I'm working on the specific case of "what does the local resolver know, and how can the local resolver get the 'best' results with what it knows?"  

>You are suggesting that checking be disabled by default on upstream queries. 
>The onus is on you to show that this does not have negative security implications.

I'm suggesting the CD bit be set on upstream queries covered by a local TA, not on all queries.

And actually, the onus is on both of us to show that our approach is "best" for some value of best.  4035 doesn't describe the setting of the CD bit in the case of a local trust anchor covering the query.  This is what this discussion is about.

With respect to "negative security implications", I'm also including in it "denial of service" or "availability" - as in the inability of the local resolver to bypass a broken upstream to be able to return data to its clients as a possible negative security implication.  You seem to be of the opinion that this is a bad idea.  Not sure why.

>No : a break does not cause SERVERFAIL, it causes Insecure (AD=0 in the response). A break can be either because
>a parent does not yet allow DS records to be uploaded, or because the local resolver doesn't support
>an algorithm necessary for the authentication chain to be completed.

I think we're reading different RFC4035s.  If I send a query upstream WITHOUT the CD bit set and with the AD bit set, if the upstream does a validation of the data and the validation fails, I get an RCODE 2 - SERVFAIL. - RFC4035, section 5.5.   

If I send a query upstream WITH the CD and DO bits set (and per -11  or the AD bit set), I may get data returned with the AD bit set, but if the AD bit is cleared, all that means the data is unvalidated (NOT necessarily bogus) - either because it came from the auth server, or an upstream validating resolver didn't have a covering TA.  I can't infer either.

>In either case this condition may be resolved by the upstream resolver, affording more security than otherwise.

In either case this condition may be exacerbated by the upstream resolver, affording less availability than otherwise and causing DNSSEC to be yanked out by its roots by resolver operators who need DNS data more than validated DNS data.

>[ rest snipped]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 24 May 2010 14:40:13 -0400

At 02:03 PM 5/24/2010, George Barwood wrote:
>Right, but seems to be missing the point.
>I will give an example that is reasonably realistic, to see if that helps.
>
>In July, I configure a device (maybe some kind of backup device) at our company office. 
>It's a "black box", auto-configured to use the local (validating) forwarder(s), but it also performs
>local authentication.
>
>Two years later, some TLD is signed with a new algorithm, to say allow a transition to BNAME, or whatever.
>The local validating forwarder(s) are updated to the new algorithm, but unfortunately no update is
>available for the old device (the company has gone bust). If the device is using CD=0 on it's
>upstream queries, I'm still fairly happy that a decent level of security is in place ( the local network
>has good physical security ). However if the device is using CD=1 on it's upstream, it's no good. 
>I will either have to throw it away or live with no DNSSEC for the TLD in question - and that's
>assuming I even remember that the device exists, and there is a potential security issue.

If you set CD=1 on the upstream (because the black box has a covering TA), the raw data comes to the black box and the box starts dropping data on the floor, because it can't validate it.

You, as the local operator - responding to client complaints, now delete the non-usable Trust Anchors and the box starts using CD=0 for those previously covered queries.  If there's an upstream validator, validation is done, otherwise the unvalidated data is passed to the client.

Worse is if the upstream resolver is a black box and you don't set CD=1 on the upstream.  All of the sudden you start getting SERVFAIL and you can't actually track down who owns that black box.  If you have no way of setting the CD bit in the upstream, you can be really screwed.

So - got a better example?

Mike