Subject: DNSSEC - Off-tree signatures

From: Mike StJohns <[email-masked]>
Date: Sun, 26 Nov 2006 21:08:07 -0500

One of the comments I got even from the "con" side of the discussion 
at the IETF was that it would be really nice if off-tree signatures 
could be incorporated into the current DNSSEC protocols.

My comment back is that I didn't believe it to be possible for a PNE validator.

My reasoning on this runs something like:

A trust anchor configured at a resolver tells the resolver that 
everything at that trust point and below should have a valid proof of 
existence, or a proof of non-existence or a secure delegation into a 
unsecure zone.  E.g. a trust anchor for .COM says that everything 
under .COM is either signed, or that there is a signed NSEC proving 
that a DS record for a sub zone does NOT exist.

If a DNSSEC aware client makes a query into the DNS tree for data 
that is not subordinate to one of the trust anchors it knows about 
(e.g.  it olny knows about .COM, the query is for "FOO.NET"), that 
data is automatically treated as not-signed by the validator.  Say 
that foo.net has an off tree signature - there's no way to convey to 
the validator that this part of the tree is signed - a simple 
deletion attack could remove any DNSSEC data and the validator 
wouldn't know the difference.

DLV gets around this by forcing a lookup for ALL queries under a set 
of registry points to ALL registries that could possibly have 
information about that query name.    (E.g. resolver has DLV 
registries configured for .COM, <root> and .MIL, but no trust anchors 
for anything in that space - a query about example.mil will result in 
queries to the both the <root> and .MIL to find out if example.mil 
should be considered signed).  Unfortunately, that means that ANY 
query under the space indicated as served by a registry will require 
a query into the registry. For this example, at least 3 distinct 
queries just to find out that example.mil isn't signed.

SO gets around this by only caring about a proof of existence rather 
than one of non-existence.

The question for discussion here - is there a better scheme for 
off-tree signatures than DLV that still preserves the ability to 
securely determine whether a branch of the DNS tree should be signed?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Nov 2006 09:18:33 -0500

At 21:08 -0500 11/26/06, Mike StJohns wrote:

>The question for discussion here - is there a better scheme for off-tree
>signatures than DLV that still preserves the ability to securely determine
>whether a branch of the DNS tree should be signed?

That depends on what you mean by "better."

(Synopsis - this is a historical recanting of my memory of the 
development of DNSSEC in the 90's regarding off-tree signing.  I 
don't have a better solution but present what we thought of back then 
and why we settled on writing RFC 3008.)

When we {Olafur, Brian Wellington, and I then all working for Russ at 
TIS} were preparing for RFC 2065, the identifier of the signing key 
in the SIG record was not tied to the parent.  An explicit goal was 
to have cross-validation, etc., and the ability for a grandparent to 
sign a zone's keys incase the parent was unsigned.

RFC 3008 came along because we the implementers did not have the 
resources to mock up a safe validation process to meet that goal. 
The vulnerability was a potential DOS attack against the validator by 
getting it to validate a piece of data requiring an unbounded number 
of KEY RR requests.  The general solution was to rely on "local 
policy" to decide whether a particular KEY RR ought to be sought in 
the process, i.e., whether the KEY RR was owned by an authorized 
signing of the data.

We imagined that an RR set could have a set of SIG records with KEY 
RR identifiers indicating keys from different zones (from each other 
and from the data set).

The first problem was that we (the implementers) would have needed to 
invent a policy "language" and add that parser, et.al. to BIND 8.  We 
weren't up to that.

I recall trying many schemes, one that even involved an explanation 
involving a bunch of clipped paper clips to show how by "signing up 
the tree" you could begin with any zone and validate data anywhere. 
E.g., tislabs.com signs .com, signs the root, signs .net, signs 
arin.net, etc.  Obviously, the thought that 750,000 delegations in 
.COM would then have to sign the .COM keys was nuts.  Especially as 
.COM has grown to, umm, a million or more since those days.

The reason RFC 3008 was written was that we felt it was better to 
start with a highly restrictive policy and then find ways to loosen 
it later, rather than the reverse.

In 1999, the FMESHD project [1] included an attempt to open up the 
DNSSEC validator policy.  Nothing came of that.  After that, no one 
really tried to "fix" this until DLV came along.  (We were too busy 
trying to roll operations into DNSSEC.)

So, the answer is yes, there are "better" schemes, at least 
theoretically.  The assumption that by looking at the trust anchors 
you could determine if data was in an secured part of the tree is an 
assumption that is an accident of history, of RFC 3008.

DNSSEC is supposed to be for the benefit of the validator and not the 
server, and it is best evaluated from the data up to a point of 
trust.  (It is the path to the point of trust that gave us fits.) 
Over the years, the view of DNSSEC has shifted to the service side 
implications, about "securing a zone" and "identifying an island of 
trust."  The shift to the server side is because of the realization 
that that is where the resources (money) are for DNSSEC, the 
computing power and the control.  It was supposed to be about the 
clients protecting themselves.

There is a rich set of policies for authorizing dynamic updates 
starting in BIND 9.3, richer than that in 9.2.  Such an advancement 
would be needed for DNSSEC to allow a validator to specify what 
"signer authorization policy" it prefers.  Perhaps the key needs to 
be at least one label up for a KSK.  Perhaps for a ZSK, one at the 
same depth or higher is okay - but then we get into other hairy 
policy limits.

[1] - http://isi.edu/div7/project_overviews/fmeshd_overview_.html

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: David Blacka <[email-masked]>
Date: Mon, 27 Nov 2006 17:34:42 -0500

> theoretically.  The assumption that by looking at the trust anchors you
> could determine if data was in an secured part of the tree is an

I'm not sure that is true.

For DNSSEC to work, a validator must be able to ask the question "should
this response be signed?" and be able to determine a definitive answer
that is difficult to forge.  DNSSEC accomplishes this by following a
rigid chain of trust, DLV does so by issuing a query for the DLV record.

Supplying a false answer to this question is a downgrade attack.

Mike's DNSSEC-light proposal solves this problem by declaring the
downgrade attack a non-problem.  This makes off-tree chains of trust
much easier to implement.

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 09:28:30 -0500

>rigid chain of trust, DLV does so by issuing a query for the DLV record.

Yes, the chain is rigid, but it need not be, that was my point.  DLV 
is one degree less rigid than what's in RFC 3008.

>Supplying a false answer to this question is a downgrade attack.

I'm not sure what "this question" is...

Perhaps there is no better model for DNSSEC than RFC 3008+DLV, but it 
is not because the design of DNSSEC sought that.  Perhaps it is 
ultimately impossible in theory too, but we never worked on finding 
that proof.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: David Blacka <[email-masked]>
Date: Tue, 28 Nov 2006 16:14:53 -0500

Edward Lewis wrote:
> Yes, the chain is rigid, but it need not be, that was my point.  DLV is
> one degree less rigid than what's in RFC 3008.
>

The question I started out with: "Is this response supposed to be signed?"

> Perhaps there is no better model for DNSSEC than RFC 3008+DLV, but it is
> not because the design of DNSSEC sought that.  Perhaps it is ultimately
> impossible in theory too, but we never worked on finding that proof.

I'm suggesting that the approach you+others were investigating all that
time ago was not going to work out, because it didn't account for
answering the "Is this response supposed to be signed?" question.

I'm not saying that 3008 was inevitable.  I'm just trying to state the
central issue that some other technique would have to solve.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 17:16:43 -0500

>answering the "Is this response supposed to be signed?" question.

Believe me, sigh, I only wish I was paid by the hour!

To disagree a bit - the "is this supposed to be signed" was the 
central question of all of the schemes.  The achilles' heel [1] was 
keeping the DNSSEC processing time bounded and the "chain of trust" 
only passing through authorized zones.

Either way, if you do falsify the answer to the question, it's a 
downgrade one way or another.

[1] http://en.wikipedia.org/wiki/Achilles%27_heel
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar