Subject: [dnsext] Design team report on dnssec-bis-updates and CD bit

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Jul 2010 10:21:08 -0400

Dear colleagues,

On 2010-07-06, there was a design team meeting in Bethesda, MD, to
address the issue of setting the CD bit in the dnssec-bis-updates
draft.  David Blacka, Olafur Gudmundsson, Mike StJohns, and Andrew
Sullivan attended.  We convened the meeting because there had been a
lot of discussion on the mailing list about the handling of the CD
bit, and we didn't seem to be reaching a resolution.  The meeting was
very helpful to the chairs, and we thank David and Mike for taking the
time.

In the meeting, we concluded by describing three different models for
how the CD bit is to be treated and used by a validating resolver
(i.e. one that has at least one trust anchor), and what interaction
this has with a local cache.  We based these models on RFC 4035, on
the discussion we saw on the list on this topic, and on what we think
people have implemented.  We want one, and only one, of these models
to be described in the draft as the standard model.  These models are
outlined below.

The design team noted that the generic model of stub resolver talking
to recursive resolver talking to authoritative server, while the most
common for any given query, is not the only possible model.  In
particular, it is possible (by configuration or proxy interception)
for there to be more than one recursive (and possibly validating)
resolver between the client and the authoritative server.

The design team reaffirmed that 4035 does not adequately address the
setting of the CD bit on queries originated, forwarded or recursed
from an intermediate validating resolver.  The team relied on the
assumption that an intermediate validating resolver is required to set
CD=1 for any upstream query where the original query also had the CD
bit set.  That restriction has been explicit in the dnssec-bis-updates
draft since version -09, and participants thought it uncontroversial.
The following tables reflect that consensus.

The tables that describe the model have five columns.  The first
column indicates the value of the CD bit that the resolver receives
(for instance, on the name server side in an iterative resolver, or as
local policy or from the API in the case of a stub).  The next column
indicates whether the query needs to be forwarded for resolution (F)
or can be satisfied from a local cache (C).  The next column is a line
number, so that it can be referred to later in the table and later in
our discussion.  The next column indicates any relevant conditions at
the resolver: whether the resolver has a covering trust anchor, and so
on (if there are no parameters here, the column is empty).  The final
column indicates what the resolver does.

The tables differentiate between "cached data" and "cached RCODE=2".
This is supposed to be shorthand; the point is that one has to treat
RCODE=2 as special, because it might indicate a validation failure
somewhere upstream.  The distinction is really between "cached
RCODE=2" and "cached everything else".  If you have a better way to
capture this in short language, your suggestion would be appreciated

The tables are probably easiest to think of in terms of describing
what happens when a stub resolver sends a query to an intermediate
resolver, but they are perfectly general and can be applied to any
validating resolver (e.g. a resolver of any sort forwarding to another
resolver).

Model 1: "always set"

This model is so named because the validating resolver sets the CD bit
on queries it makes regardless of whether it has a covering trust
anchor for the query.  The general philosophy represented by this
table is that only one resolver should be responsible for validation
irrespective of the possibility that an upstream resolver may be
present and with TAs that cover different or additional QNAMEs.

CD F/C     line         conditions              action
=======================================================================
1   F       A1                                Set CD=1 on upstream query
0   F       A2                                Set CD=1 on upstream query
1   C       A3                                Return the cache contents
                                                 (data or RCODE=2)
0   C       A4          no covering TA        Return cache contents
                                                 (data or RCODE=2)
0   C       A5          covering TA           Validate cached result and
                                                 return it.

Model 2: "never set"

This model is so named because it sets CD=0 on upstream queries for
all received CD=0 queries even if it has a covering trust anchor.
("Never" is really too strong: obviously, if the query arrives at the
resolver with CD=1, it must set CD when it performs the query as well.)
The general philosophy represented by this table is that more than one
resolver may take responsibility for validating a QNAME and that a
validation failure for a QNAME by any resolver in the chain is a
validation failure for the query.

CD F/C     line         conditions              action
=======================================================================
1  F       N1                                Set CD=1 on upstream query
0  F       N2                                Set CD=0 on upstream query
1  C       N3           cached data          Return cached data
1  C       N4           cached RCODE=2       Treat as line N1
0  C       N5           no covering TA       Return cache contents 
                                              (data or RCODE=2)
0  C       N6           covering TA &        Treat as line N2
                         cached data was 
                         generated with CD=1
0  C       N7           covering TA &        Validate and return
                         cached data was 
                         generated with CD=0

Model 3: "sometimes set"

This model is so named because it sets the CD bit on upstream queries
triggered by received CD=0 queries based on whether the validator has
a TA configured that covers the query.  If there is no covering TA,
the resolver clears the CD bit in the upstream query.  If there is a
covering TA, it sets CD=1 and performs validation itself.  The general
philosophy represented by this table is that a resolver should try and
validate QNAMEs for which is has trust anchors and should not preclude
validation by other resolvers for QNAMEs for which it does not have
covering trust anchors.

CD F/C     line         conditions              action
=======================================================================
1  F       S1                              Set CD=1 on upstream query
0  F       S2           covering TA        Set CD=1 on upstream query
0  F       S3           no covering TA     Set CD=0 on upstream query
1  C       S4           cached data        Return cached data
1  C       S5           cached RCODE=2     Treat as line S1
0  C       S6           cached data was    Return cache contents
                         generated with 
                         CD=0
0  C       S7           cached data was    Validate & return cache
                         generated with     contents
                         CD=1 & 
                         covering TA
0  C       S8           cached RCODE=2     Return cache contents
0  C       S9           cached data        Treat as line S3
                         was generated 
                         with CD=1 &   
                         no covering
                         TA

Please offer your thoughts on these models and state which of them you
think should be in the draft as the way to handle the CD bit.  We will
devote some time in the Monday Maastricht session to this issue.  We
want to bring it to a close at that meeting.

Best regards,

Andrew (as design team stenographer)

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

---

From: [email-masked]
Date: Fri, 9 Jul 2010 22:04:59 +0000

On Fri, Jul 09, 2010 at 10:21:08AM -0400, Andrew Sullivan wrote:
> Sullivan attended.  

	so the We in the para above is the design team of 
	yourself, David, Olafur, and Mike.  This does not meet 
	the WG criteria of "five" reviewers.

	Perhaps the WG would like to weigh in on the recommendation
	that the design team came up with, ie that only one of the
	models be described as the "standard" model.

> want to bring it to a close at that meeting.

	I guess the questions I have, before proceeding down the selection
	process is, Are there good reasons to use different models? (I can think
	of reasons to use other interpretations, fwiw).  Is there
	a compelling reason to select only one model?  If one is standard,
	are the others still optional or will they be forbidden?  If they
	are to be forbidden, can we document why?

--bill

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 10 Jul 2010 11:05:19 -0400

> 	the WG criteria of "five" reviewers.

This is orthogonal, design team can be of any size, the output of an
design team can be one of:
	a proposal of way forward
	a list of options
	a comment on a particular design.
	a statement of failure to reach conclusion

In this case we documented number of options and it is up to the working 
group to discuss which one of the options to prefer or to say
that some/all will work together.

The problem we have had in the past was that there was no concise crisp
description of polices,  MSJ as he came closest with his flow graph,
and his graph inspired the table format.
We are not making any claims that this is the complete space of policies 
and if there are other polices we hope that people put them forward in 
the same format.

> 	models be described as the "standard" model.

Please, Please, Please.
The design team  (hopefully) worked on creating a framework for more 
productive discussion.

> 	are to be forbidden, can we document why?

This is an excellent question,
If I rephrase it:
Will it hurt interoperability if different validators implement 
different models ?
Sub-question: will it hurt deployment if different models are in use ?

	Olafur

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 11 Jul 2010 05:35:15 +0900

> a statement of failure to reach conclusion

Then, you are biased from the beginning.

An important output is:

	a proposal to stop and go backward

or

	a lack of options

or

	negative comments on all the available designs

or

	a reached conclusion that the problem is unsolvable

which should have been the output of many design teams.

> In this case we documented number of options

Many options is often equivalent to no options.

						Masataka Ohta

---

From: [email-masked]
Date: Sat, 10 Jul 2010 21:33:42 +0000

> 	a statement of failure to reach conclusion

	hum... this kind of makes the IETF WG process subject to capture,
	don't you think?  According to you, a design team of one can make
	a statement about failure to reach conclusion...  Thats a pretty 
	low bar.

	that being said, this work was the result of just four people.

> that some/all will work together.

	except Andrew, as spokesperson for the design team cast a 
	bias - not just the presentation of options with a request
	to the WG to come to consensus.  To compound influence, there
	was an inferance that the WG chairs would close this topic
	by the next IETF... just 14 days.  Is there a reason for the
	short suspense on this item and not with the other items on
	the WG agenda?

> and his graph inspired the table format.

	Yup.. I really liked the flow graph.

> and if there are other polices we hope that people put them forward in 

	'Cept the intent to  close discussion in 14 days... :)

> The design team  (hopefully) worked on creating a framework for more 

	Well, for what its worth, I can see use cases for at least two
	of the options that the DT produced.  I would be sad if in its
	haste, the WG allowed a single option to be "fast-tracked" through.

> >>want to bring it to a close at that meeting.

	Unfortunately, I will not be at the meeting on Monday - I'll be 
	in transit.  So good luck and I hope the DT picked correctly.

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 10 Jul 2010 22:29:41 -0400

>    a statement about failure to reach conclusion...  Thats a pretty 

To be clear, nobody is suggesting this is a WG product. If it were, we could rule on consensus rather than discussing. But we brought this input to the WG as our considered opinion. 

>    to the WG to come to consensus.  

The report says that we want one option, that's true. I personally prefer that the WG coalesce around one because I think a completely indeterminate behavior on the part of intermediate resolvers would be very bad for user experience. I'd be interested in counter arguments. 

> To compound influence, there

Actually, I don't think an inference was needed. And I didn't imply anything. I stated that if the WG couldn't reach consensus, we could leave this topic out of the draft on the grounds that we have no consensus. That's not a threat; it's the chair's job to say such things. As it transpires, I believe now that the tables are a significant enough improvement over the existing 4035 text that we should include them all if need be. But I see no reason why we cannot at least settle on a predictable default.

A

-- 
Andrew Sullivan
<[email-masked]>

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 12 Jul 2010 11:22:18 +0800

----- Original Message ----- 
From: <[email-masked]>
To: "Olafur Gudmundsson" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, July 11, 2010 5:33 AM
Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit

> that being said, this work was the result of just four people.

any proposal or conclusion or suggestion submitted by individual or 4-people group or design team must be discussed or approved by the WG.
without the WG approval, the design team report or conclusion will not be a wg conclusion.
This  Design team report is just a report, not a wg conclusion. so you don't worry "this kind of makes the IETF WG process subject to capture".
Since these four people sacrificed their own time to discuss the issue and produce a report, we should encourage them to do so.
If our WG discussion based on their report, our wg will move faster.
so I think that, we should thank these four people for their hard work.

Jiankang Yao

---

From: Michael Graff <[email-masked]>
Date: Sun, 11 Jul 2010 23:59:46 -0500

On 7/9/10 9:21 AM, Andrew Su
> want to bring it to a close at that meeting.

I may make some sense to list the behaviors of the common resolvers, and
define what problems we're trying to fix by selectively setting the CD=1
flag.  There was mention that there was lack of agreement, but no
reasons (pros, cons) for the various choices really.

Please also note that you might not know that you have a covering TA for
the name in question in all cases, specifically DLV or when learning
about the existence of DNSSEC does not start from the parent and move
into the child, but moves the other way.  Which some resolvers implement.

Also, just because a query did not have CD set, it does not mean the
next one won't, and I believe it's against the RFCs to query for RRSIG
or NXT records.  This would mean more queries, and to be safe, probably
two caches in the resolver, one for CD=1 and one for CD=0.

--Michael

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 12 Jul 2010 12:13:37 +0200

Hi,

I sort of agree with Michael and George, that there are multiple
options, this seems to be a list of what local-policy a resolver could
implement.  What a CD flag does works fine: the upstream either gives
the unaltered, unabridged data or does "funky policy" on it.  Below I
attempt to list some pros and cons.

* After root key deployment, it is likely that if a trust anchor is in
place, it is the root key.  Thus everything falls under the trust
anchor.  And the tables are not useful in that case.
* CD=1 in general makes debugging DNSSEC easier.  This for the question
'help or hinder DNSSEC deployment'.
* intelligence at the end points.  CD=1 makes sure that the end point is
doin' the do, and I think we ought to promote that principle.
* Seems that the current implementations all set CD=1, but I could be
mistaken.
* If you want to improve current implementations, 'CD=1 cache MAY be
validated in order to attempt to not cache nonvalidatable data', so
using its trust anchors simply to attempt to flush bogus data out of the
cache (but not refusing to serve contents).
* The only case I can think of that has 'cooperating validators with
different trust anchors' in today's dnssec deployment is a firm that has
a local DNS zone signed, and also uses an upstream ISP cache.  But it
would be trivial to add the public internet trust anchor to the firm's
validators?

Therefore I think the always-set is simpler.  I think these tables are
not appropriate in dnssec-bis-updates.

Best regards,
   Wouter

---

From: Anthony Iliopoulos <[email-masked]>
Date: Mon, 12 Jul 2010 11:15:47 -0500

Greetings all,

Just some thoughts that might help stir further discussion..

> present and with TAs that cover different or additional QNAMEs.

This is a sane expectation (one resolver being responsible for
the validation, and only *that* resolver). Given that there has
been some desire for pushing the entire validation to the
stub, this model has no surprise factor. I assume that the counterargument
here is, why would a validating resolver ever set the CD flag on
upstream queries when it is missing any covering TA for the QNAME ?
Expectation for consistent (validation, resolution) behavior, and
enforcement of policy. If a stub trusts a resolver/forwarder,
it also trusts its local policy, i.e. the set of configured TAs,
and any kind of validation restrictions.

> validation failure for the query.

This option places blind trust in all the intermediate validators. It's
a kind of "opportunistic" dnssec, in a sense. It's pushing the validation
away from the stub too, in a non-deterministic manner.

> validation by other resolvers for QNAMEs for which it does not have

It really looks like this is a policy issue. The real question here is,
should the standards offer flexibility or enforce one of the above models ?
What are the implications of not officially settling with a single model ?
Under which scenario would it be desired to have more than one validators
between a stub and the authoritatives, configured with a differing set
of policies ? (assuming these validators are under the same domain of control)

What if the validators are *not* governed by the same policy,
and are under control of separate parties ? Would then models 2,3
be acceptable at all (i.e. rely on an unknown or disagreeing
3rd party policy for validation) rather than simply comply with the
local policy (and fail resolution if the local policy leads to it,
isn't that the purpose of a policy, especially when this is
a security-related protocol ?)

Models 2,3 can lead to some "unexpected" conditions. What if one of
the upstream intermediate validators has a stricter policy than
the "local" validator ? What about when it has a more liberal policy ?

In general, since there are no protocol means of communicating TA
configuration and validation policies between validators, aren't models
2 and 3 placing more faith than they should on their upstreams ?
Would it even make sense or would there be any benefit to have any kind
of trust relationship protocol between validators ? Models 2 and 3 appear
to be implicitly "forcing" stubs to transitively trust all of the upstream
validators (and their respective policies).

I would generally support Model 1, that is, push all validation as
closest to the stub as possible (or to the closest validator to
the querier). Ensure that the DNSSEC security material is propagated
intact from the authoritative back to the first validator under *all*
conditions (models 2,3 can obviously prevent that).

Regards,
Anthony

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 26 Jul 2010 03:43:15 -0400 (EDT)

<editor hat off>

Colleagues,

Many thanks for putting this report together.  I appreciate the 
clarity.  Your descriptions of model 1 and 2 are complete, as best as 
I can tell.

I prefer "never set" (model 2).  It allows upstream caches to help 
out: if the local cache doesn't have a full set of trust anchors, 
maybe the upstream can validate answers in larger part of the 
namespace.  Similarly, if there are holes in the secure tree, perhaps 
the upstream has trust anchors for zones further down the tree.

I conur with Andrew's statement (on July 10th) about user experience. 
One model is best.  I'm happy for it to be a SHOULD; I can easily see 
the case where a validator would want to use model 1, perhaps as a 
configuration option.

-- Sam