Subject: Re: [dnsext] Setting CD=1 on upstream queries

From: Michael StJohns <[email-masked]>
Date: Fri, 11 Jun 2010 15:03:09 -0400

At 01:57 PM 6/9/2010, George Barwood wrote:
>It has been suggested that a resolver MAY/SHOULD/MUST set CD=1 on recursive upstream
>queries to forwarders when  responding to a CD=0 query for which there is a trust anchor.
>
>Possible advantages:
>
>A1 Less load on upstream resolver.
>A2 May be faster.
>A3 Avoids potential upstream validation failures.

A4 - places the authority and responsibility for validating answers closest to the querier and provides a local and known place to beat on when someone screws up with the signing of the root or IN-ADDR.ARPA

>Possible problems / disadvantages:
>
>D1 If there is CNAME or DNAME redirection, the response may not be covered by the trust anchor.

Since the CNAME or DNAME can actually chain through a name not covered by any trust anchor, and that can't actually be detected by the end user, this seems to be no worse than the defined behavior for DNSSEC over CNAME in general.  (I can point you to a long discussion on this from a while back, but thing secured CNAME -> unsecured CNAME -> secured CNAME - fooling with the unsecured CNAME can redirect you and you would still get a "secure" indication from the resolver)

>D2 The upstream resolver may implement an algorithm that the local resolver does not implement.

But the local resolver has no way - absent of manual configuration - to know this.  I'm perfectly happy to have a configuration item in the local resolver to clear the CD bit is specific circumstances for TA covered queries... but its probably not the best default to clear the CD bit.

Besides, I think this may actually be a red herring.  If I have a trust anchor for zone A - and its a legitimate trust anchor - then it will be pointing to an apex DNSKEY RRSet that contains a key with this algorithm, or at least that's how I understand this is supposed to work.  If the real apex set doesn't contain a key with this algorithm, then the TA is lame or bogus and needs local work to fix it.  Remember a TA has two purposes - to provide a key for validating a chain and to set a bit that says "this name tree is presumed to be validly signed".  Somewhere I remember a nice long discussion with someone that says that the apex RRSet must contain at least one key from each algorithm that signs the zone and that all entries in the zone must be signed with those algorithms.  So I should be able to get the RRSet and the appropriate RRSig and if I can't then that's just a validation failure caused one of a mistake on the local configuration, an attack in the middle (to substitute the RRSig and RRSet), or a configuration mistake on the authoritative side.

>D3 The upstream resolver may have a closer, more trusted, anchor.

Again, same response as to D2 - no way to know without configuration.  The upstream may also have a closer more broken TA which is actually acting as a denial of service attack..  The local resolver has no way absent manual configuration to determine this.  

>D4 If the local resolver is flawed, security may be reduced. Possible flaws are:
>  D4.1 Invalid trust anchor ( may have been inserted by an adversary ).
>  D4.2 Inaccurate local clock.
>  D4.3 Flaw in local DNSSEC software.

Yes, but...  The same can apply to a quantum-ly existent upstream resolver.  If your local resolver is broken, no amount of possibly non-existent upstream patching of answers is going to do anything useful.

>Disadvantages D1 and D2 may be overcome by repeating the upstream query with CD=0 if in
>fact the response cannot be fully validated locally. The other disadvantages are not decisive.
>Therefore setting CD=1 does seem reasonable.

Sorry - should have read this first - I thought you were arguing against CD=1.  

>However it does involve extra complexity and can lead to reduced performance / security
>in some situations, therefore I don't think it should be mandatory. Moreover a clarifications
>document is not a suitable place to introduce mandatory behavior that is not essential.

I think it would be reasonable to define a mandatory default behavior with an optional bypass, even in a clarification document.  4035 didn't clearly define the behavior of the resolver side of an intermediate nameserver, either for the presence of CD=1 on the query side (the language said "pass the state" didn't say set the bit in the upstream, but that's now in -11 bis), or for queries for which the resolver has a TA.  4033 is pretty clear that if you have the ability to do your own validation, you should set the CD bit to make sure you get the data you need to do your validation.

If we say "SHOULD" for the default, then RFC2119 Section suggests/requires we document the adverse affects of not doing so.  And the text for that is probably quite a bit longer than just saying "MUST"!  

I'm willing to write the explanatory text for a "MUST" - anyone else willing to step up and write the text for SHOULD if we go that way?

>Regards,
>- George

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 14 Jun 2010 09:27:43 +0200

Hi Michael,

On 06/11/2010 09:03 PM, Michael StJohns wrote:
> Since the CNAME or DNAME can actually chain through a name not
> covered by any trust anchor, and that can't actually be detected by
> the end user, this seems to be no worse than the defined behavior for
> DNSSEC over CNAME in general.  (I can point you to a long discussion
> on this from a while back, but thing secured CNAME -> unsecured CNAME
> -> secured CNAME - fooling with the unsecured CNAME can redirect you
> and you would still get a "secure" indication from the resolver)

This is not true.  The validator detects the unsecured CNAME in the
chain and does not give the result the denomination 'secure', it
indicates 'insecure'.

Trying to avoid the rest of the CD=1 or BAD cache stuff; I agree with
Andrew and Mark; and I think that these approaches for caches with
different sets of trust anchors and cooperating to some degree (over
untrusted channels?) is not something that should be done in a couple of
lines in the dnssec-bis-updates document.

Best regards,
   Wouter

---

From: Michael StJohns <[email-masked]>
Date: Mon, 14 Jun 2010 10:25:58 -0400

At 03:27 AM 6/14/2010, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Michael,
>

To be more specific it doesn't set the AD=1 bit in the reply.  As I read it, AD=0 means "unknown" not "bogus" or "unsecure".

 You also get this result if the validation is done in two parts and both are secure - the original CNAME answer by your local resolver (that has a TA covering this) and the CNAME target by an upstream resolver that validates the target data.  Both parts are secure, but the local resolver can't set the AD bit, because it can't trust the AD bit from the upstream and so can't say for itself that both are valid.

I probably should have used another word than "secured" here.   The client thinking the resolver(s) is/are protecting his could get data for a bogus target query where they might have expected a SERVFAIL.  Differing from a secure delegation to an unsecure zone, the client (and intermediate resolvers) has no way to determine whether the owner of the CNAME intended to send us into an unsecure zone - there's no indication in the CNAME of the CNAME owner's expectation of the trust state of the target.

>lines in the dnssec-bis-updates document.

I've actually tried to do in on more than a few lines, because I knew it was complex, but got push back to "make it simpler".  I agree that it can't be done in a few lines, (although I think the pseudo code I sent out in May does a pretty good job of it), and I guess I'm done trying.  

Thanks for your indulgence.

Mike

>Best regards,
>   Wouter
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2.0.14 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAkwV2e8ACgkQkDLqNwOhpPjimACfcxk6jGmQpvkqIfjpmb1eXQtn
>wg4AnRKyyK9DotpUoqbw76EyJ6nXfCF/
>=hINg
>-----END PGP SIGNATURE-----

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Jun 2010 14:39:25 -0400

Michael,

On Mon, Jun 14, 2010 at 10:25:58AM -0400, Michael StJohns wrote:
> 
> I've actually tried to do in on more than a few lines, because I
> knew it was complex, but got push back to "make it simpler".  I
> agree that it can't be done in a few lines, (although I think the
> pseudo code I sent out in May does a pretty good job of it), and I
> guess I'm done trying.

In case this hasn't been clear from the interactions we've had, the
more than a few lines that you suggested did not raise objections
because they were too long.  It was because they were too hard to
understand, which is what the "simpler" request was, I think, about.  

The pseudo-code that you sent entails a difference with RFC 4035 that,
as near as I can tell, does not attract wide support, because it is a
series of if/thens with pure entailment in them.  You argue, of
course, that that's what the specification should be doing: if you
cannot capture the rules in a set of if/then statements, then the
rules are underspecified.  I have a great deal of personal sympathy
with this view, but in the absence of a bunch more people saying
they're willing to alter the meaning of 4035 in the way you seem to
want, I don't think we're in a position to make that change.

Moreover, we actually have to produce text, not just pseudo-code, and
it would appear that there were not only disagreements about whether
we could do what your pseudo-code said, but also the right way to
capture that pseudo-code as prose.  That prose has to specify the
result in question, not the mechanism by which it is achieved.  I
think that one issue with the pseudo-code is that it tends to be read
as the latter, not the former.

Do I take the end of the paragraph above to suggest that you no longer
want to work on text for the draft, and that your previous objections
to the draft going ahead without the change you were proposing are
lifted?

Thanks,

A

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Jun 2010 16:42:44 -0400

>to the draft going ahead without the change you were proposing are

The definition of insanity is doing the same thing over and over again and expecting a different result... I doubt that my further objections will result in any different result in the end.

 So do what you need to do, as will I.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Jun 2010 18:15:22 -0400

Michael,

>  So do what you need to do, as will I. 

Since we're trying to work through the objection by doing similar
things over and over, I understand your frustration but have little
sympathy with your unwillingness to be clear.  It seems to me that we
have an item here that probably needs detailed discussion at the
Maastricht meeting, but I only want to turn the time over to it if you
haven't already withdrawn your objection.  Cryptic answers of this
sort don't actually help with making that kind of determination.

A

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 20 Jun 2010 11:29:41 -0400

We have organized a face to face meeting of the chairs, Michael
StJohns, and David Blacka (one of the editors of the document).

The meeting will take place on July 6'th, in Maryland, at 16:00 local 
time. Any member of the working group that wants to be there let us 
know, or if you want to call in we can try to arrange for a
conference bridge to be set up.

This meeting is a "design team" meeting and the results of the meeting
will be posted to namedroppers afterwards.

If you have opinion/view on this topic please post that to namedroppers
before July 2'nd.

	Olafur

---

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Jun 2010 23:22:05 -0400

Hi Andrew -

I have a bit different view of the process.

18 months or so ago I raised the objection to the text, worked with the document editor to get it at least somewhat correct and was assured that we were good to go.  Since my day job no longer involves DNS, I wandered off to do things I get paid for.  I was quite surprised with the text in the current document that as near as I can tell was crafted by one of the document editors, wasn't discussed (could have been, I might have missed it) and still didn't fix the problem.

After discovering this at the last IETF F2F meeting, I objected, and for my part to support the objection crafted a diagram that showed what I believed the appropriate DNSSEC processing of CD bit related data was at an intermediate resolver.  The diagram drew total silence and as near as I can tell.  I noted to the document editor a lack of comments and was told it would be gotten to.

Skip to the current cycle.

I restated the diagram as an if/then/else structure for discussion purposes, suggest that there is a SHOULD/MUST issues, and we immediately get tied up on my assertion that a SHOULD really should be a MUST, but there's no discussion or analysis of the generic processing model.  After a number of go arounds - mostly with George, but also with you I try and write text (5/17) that reflects the processing model.   

After a number of discussion with you on list about what I did or didn't say (mostly what I did or didn't say about George's comments)  which seemed to be of no real point, I re-submit the 5/17 text with some small changes on 5/19 to cover the issues with caching CD=1 data.  Still no evidence that you've read or considered it.

No response from you.  Finally, on 5/23 Sam drops a note about  George's note of the 5/15 which starts a long and involved back and forth with George and me that goes on for a few days and also draws a side note from Don E.  

Two weeks later - 6/7 - you start munging my 5/19 text, pointing at the arguments from George as "ample" "counter-arguments"

A few more emails later - I ask for what I thought was a simple thing - predictable name resolution behavior and point out where the text doesn't really provide any directive text - at this point I don't really care about what the default is, so much as having one.   Your response seems to be that you've decided that you will be "ruling on rough consensus" and that rough consensus seems to be to leave the broken text.

I try and repair what - in my opinion - were  the greatest issues of your text.  Your response is not encouraging.
 
Next is splitting the CD=X cache vs the CD=1 upstream queries setting into two threads.

Etc etc etc..

At some point you comment about splitting the consideration into CD=0 and CD=1 - I resubmit the if/then/else text simply to show I've actually got a model that represents this.   You complain privately to me that I'm not cooperating by not providing text.  I respond privately, that perhaps we should get a common view of the processing model first and then graft on text.  

And the wheels go around.    I've provided a) a diagram that describes what I think the processing model should be, b) an if/then/else text representation of the diagram, c) prose text that as near as I can tell maps to a and b.

In the discussions on-line I've seen no one propose an alternate processing model, nor try to describe what processing model they think is represented by 4035.  I've asked you for this a number of times, especially since you've claimed my text is inconsistent with 4035.  

I don't really have much more to say on the matter - the diagram and text represents my best understanding of appropriate processing at the Intermediate resolver for CD=X cached data and for upstream queries covered by a local resolver TA.  Unless and until someone wants to have that discussion, all I would really be doing is beating my head against the wall.  But I am happy to have that discussion.

For those who care, following Andrew's note is my analysis of 4035 - everywhere the CD bit is mentioned - and what I feel the flaws are.  This was part of the in-person discussion some 18-24 months ago, but probably was never captured in text.  My comments are in brackets.

Mike

>sort don't actually help with making that kind of determination.

[As far as I can tell, this is every scrap of text in 4035 that talks about the CD bit.]

   DNSSEC allocates two new bits in the DNS message header: the CD
   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
   is controlled by resolvers; a security-aware name server MUST copy
   the CD bit from a query into the corresponding response.

[No Issue]

   A security-aware name server does not perform signature validation
   for authoritative data during query processing, even when the CD bit
   is clear.  A security-aware name server SHOULD clear the CD bit when
   composing an authoritative response.

[No issue, but note this text as it describe mandatory behavior without actually using MUST/SHOULD/MAY.  An appropriate modification is "A security-aware names server MUST NOT perform signature validation for authoritative data during query processing... ".  I cite this because of similar omissions and mistakes later on.]

   A security-aware name server that supports recursion MUST follow the
   rules for the CD and AD bits given in Section 3.2 when generating a
   response that involves data obtained via recursion.

[No issue here, but the rules in 3.2.2 aren't complete.]

3.2.2.  The CD Bit

   The CD bit exists in order to allow a security-aware resolver to
   disable signature validation in a security-aware name server's
   processing of a particular query.

   The name server side MUST copy the setting of the CD bit from a query
   to the corresponding response.

[No issues for either of these, but interestingly enough, the setting of the CD bit is supposed to be ignored by the query receiver as noted in later 4035 text]

   The name server side of a security-aware recursive name server MUST
   pass the state of the CD bit to the resolver side along with the rest
   of an initiating query, so that the resolver side will know whether
   it is required to verify the response data it returns to the name
   server side. 

[There is no text anywhere else in the document that indicates what the setting of the CD bit in an upstream query should be - "pass the state of the CD bit" does not say to set the upstream bit.  If there is a validating resolver upstream of this intermediate resolver, then not setting CD=1 may result in a RCODE=2 error even if the local resolver could have verified the data.  So this section should actually require CD=1 in the upstream if the CD bit is set in the query.]

   If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its local
   policy requires.  Thus, the resolver side of the recursive name
   server need not perform authentication on the RRsets in the response.
   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question. 

[The "SHOULD" and "if possible" are not useful without explanatory text.  RFC 2119 says "Document authors should take the time  to elaborate the security implications of not following recommendations" which suggests that this section is incomplete.  E.g. text should be included here that describes when its OK not to "return the requested data" and actually, probably should define the error code.  In any event, given other text here, its clear that the resolver should get out of the way and return the raw data - its stated two or three times]

   **That is, by setting the CD bit, the
   originating resolver has indicated that it takes responsibility for
   performing its own authentication, and the recursive name server
   should not interfere.

[The "should not interfere" buttresses my argument that the CD bit means "get the hell out of my way and give me the data straight from the source"]

   If the resolver side implements a BAD cache (see Section 4.7) and the
   name server side receives a query that matches an entry in the
   resolver side's BAD cache, the name server side's response depends on
   the state of the CD bit in the original query.  

[The section describes what can happens to a CD=0 upstream query that is locally unvalidatable.  What about data retrieved by a CD=1 upstream query that is cached, but not covered by a local trust anchor?  Normal DNSSEC practices suggest that later CD=0 queries can't use the CD=1 cached data (because the data might have missed an upstream validation), but I find nothing covering this case.]

   If the CD bit is set,
   the name server side SHOULD return the data from the BAD cache; if
   the CD bit is not set, the name server side MUST return RCODE 2
   (server failure).

[What should the resolver do instead if it doesn't return the data from the BAD cache?  Send an error code, or requery upstream or something else?]

   ***The intent of the above rule is to provide the raw data to clients
   that are capable of performing their own signature verification
   checks while protecting clients that depend on the resolver side of a
   security-aware recursive name server to perform such checks.  Several
   of the possible reasons why signature validation might fail involve
   conditions that may not apply equally to the recursive name server
   and the client that invoked it.  For example, the recursive name
   server's clock may be set incorrectly, or the client may have
   knowledge of a relevant island of security that the recursive name
   server does not share.  In such cases, "protecting" a client that is
   capable of performing its own signature validation from ever seeing
   the "bad" data does not help the client.

[We've gotten to the end of the major section describing CD handling without ever any requirement to set the CD bit in the upstream query.  Obviously, for recursive upstream queries that are the result of CD=0 queries, it makes no sense to set CD=1 unless this resolver has a TA covering the query.  Given that text at ** and *** this suggests that if you have a TA covering the query you should, absent of local security policy, set CD=1 in the upstream query.]

4.2.  Signature Verification Support

   A security-aware resolver MUST support the signature verification
   mechanisms described in Section 5 and SHOULD apply them to every
   received response, except when:

   o  the security-aware resolver is part of a security-aware recursive
      name server, and the response is the result of recursion on behalf
      of a query received with the CD bit set;

[I *think* this is OK and basically in agreement with my suggestion that CD=1 data covered by a TA can be cached without immediate validation]

4.6.  Handling of the CD and AD Bits

   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.

[This is a gratuitous MAY.  The sentence can be re-written without loss of meaning to "The setting of a query's CD bit by a security aware resolver indicates the resolver takes responsibility...". This restatement is in line with previous statements in 4035 about the purpose of setting the CD bit.]

   See Section 3.2 for the effect this bit has on the
   behavior of security-aware recursive name servers.

   ...

   A resolver MUST disregard the meaning of the CD and AD bits in a
   response unless the response was obtained by using a secure channel
   or the resolver was specifically configured to regard the message
   header bits without using a secure channel.

[As I noted above in the comments to setting the bits in the response.  

Much of the text in 4035 is written as if the only possible querier for a recursive validating resolver is a stub resolver - where it might be possible to have such a secure connection.  The reality is that with various configuration directives and IP redirection, there can be a chain of intermediate resolvers between a stub and the authoritative server.]

4.7.  Caching BAD Data

   ... This document refers to a cache of data with
   invalid signatures as a "BAD cache".

[CD=1 data not locally validatable probably needs to be put in an UNKNOWN cache or thrown away?]

4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless it is requested by the application
   layer, as by definition, a non-validating stub resolver depends on
   the security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy.

[This section has an unspoken assumption - that it has a single root trust anchor.  I infer this from the text that sets the CD bit without consdering you might not be able to do the validation.  The default policy (absent an indication from an application) should be to set CD=1 if the stub resolver has a covering TA and clear it if it doesn't.  It may have a local policy that varies from this.  The SHOULD's here may also require 2119 elaboration.]

5.5.  Resolver Behavior When Signatures Do Not Validate

   If for whatever reason none of the RRSIGs can be validated, the
   response SHOULD be considered BAD.  ****If the validation was being done
   to service a recursive query, the name server MUST return RCODE 2 to
   the originating client.  However, it MUST return the full response if
   and only if the original query had the CD bit set.  Also see Section
   4.7 on caching responses that do not validate.

[****This seems to conflict with section 3.2.2 which says "the resolver side of the recursive name server need not perform authentication" if the CD bit is set.  You can't return an RCODE 2 if you don't attempt validation.]

7.  Security Considerations

   ....

   An active attacker who can set the CD bit in a DNS query message or
   the AD bit in a DNS response message can use these bits to defeat the
   protection that DNSSEC attempts to provide to security-oblivious
   recursive-mode resolvers.  For this reason, use of these control bits
   by a security-aware recursive-mode resolver requires a secure
   channel.  See Sections 3.2.2 and 4.9 for further discussion.

[For the CD bit, this is might be correct for an oblivious stub to a validating resolver, but not correct between two security aware resolvers.]