Re: [dns-wg] Just another lookaside zone

[Alexander Gall gall@localhost]

On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke lutz@localhost said:

> * Alexander Gall wrote:
>> Why do you include DLV Records for Zones that are below a secure entry
>> point (those you call "chained")?  They will never be used unless the
>> parent zones become insecure.

> My tests show, that some resolvers only go one step back to the origin to
> check the lookaside data. So if you query for host.sub.do.main, these
> resolvers do only query for host.sub.do.main.trust.an.chor and
> sub.do.main.trust.an.chor.

But DLV is only applied to the apex of a secure subtree.  Let's take
0.176.195.in-addr.arpa as an example.  This involves two secure
delegations.  The resolver walks up the tree using regular DNSSEC
until it finds that 195.in-addr.arpa is insecure.  No DLV is involved
up to this point.  Only then does it try to see if it can authenticate
the DNSKEY of 195.in-addr.arpa with DLV.  The sub-zones are never
considered for DLV.  I think that doing anything else is just plain
broken.  But then again, there is no spec how DLV is supposed to work,
so who can say what's right ;-)

> I have to dig this problem much deeper, to see iff this is a configuration
> or software issue.

> In order to keep the lookaside zone useful, I included the subzones.

> OTOH it's possible, that the parent zone becomes unsigned. In this case the
> sub zones become new SEPs. If would be the only reason, I'll move the DLV
> entries to TXT entries in order to keep them as a backup.

> Furthermore, I regulary check the validity of the DNSKEYs with the DS parent
> entries to detect errors in chaining (i.e. after rollover errors).

Interesting.  And what do you do when the DS doesn't match the DNSKEY?
For a rollover, if both keys (old and new) are in the DNSKEY RRset and
the RRset is signed by the old key, you can safely roll the DS as
well.  In all other cases, you *must* keep the broken chain.  This
will render the zone bogus, but this is precisely what should happen.

>> What exactly does "DNSKEY unchecked, DSSET given" mean?  I suppose
>> that you have received the DSSET by the maintainer of the zone through
>> an authenticated channel (if not, you shouldn't add the DLV record at
>> all).  Why doesn't that make it a secure entry point and why should
>> you "check" the DNSKEY?

> This entry means: Somebody added a zone. This process generates the DS entry
> from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC
> authenication, so you can't add a sub zone of a signed parent zone without
> correct chaining. I should add the validation step for the person, who adds
> this zone, of course. Thanks for this suggestion.

But you don't need DLV if the parent zone is signed!  This is covered
by plain DNSSEC.

> The daily maintainance check "drops" all entries an requeries them using the
> old lookaside zone. Only authenicated responses are used to rebuild the zone.

I'm not sure I understand the use of this.  Can you give an example
of what new information you can discover this way (apart from catching
roll-overs in progress)?

> In this step the parent chaining is checked, too. And sub zones are added, if
> possible using AXFR or (on dlv.verisignlabs.com) by NSEC traversing.

> For new SEPs there exists currently no trustly off-band validation. Because
> everybody can set up a signed zone, any attacker can sign any zone unter his
> control and provide any typical validation. I only check, that the real zone
> is really signed. I do not trust other name servers than the ICANN root (and
> myself).

Many of the current islands of security publish their SEPs over https.
This looks all right to me if you check the certificates carefully.

I think you should not accept unauthenticated SEPs at all.

> Of course it is possible to attack to my infrastructure in order to fool my
> name servers.

>> Why do you include DLV records for zones that you know are broken?

> The check is done from my point of view. I do not assume permanent access to
> every zone in the internet. Some broken zones might be truly operational in
> other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs.
> I also assume that demo.netsec.tislabs.com is operational on tislabs.

Then you can probably also assume that they configure their resolvers
with their own trusted keys and don't use your DLV zone :-)

> It might be helpful for operators to have an outside view to this zone.
> There might be an TCP/53 block between AS15725 and the authorized name
> servers.

> The name servers might be offline or the zone is expired on the secondaries.
> There even might be an routing loop like this one:
> traceroute to dnssec1.jprs.co.jp (2001:200:132::2)
> 	 from 2001:4bd8:0:666:280:adff:fe1e:79ba
> ...huge IPv6 delay on C&W backbone in USA...
> 12  pc8.otemachi.wide.ad.jp (2001:200:0:4401::11)  299.067 ms
> 13  otemachi.dnslab.jp 	    (2001:200:132:4::2)    299.889 ms
> 14  fuundo.dnslab.jp 	    (2001:200:132:5::1)    301.206 ms
> 15  otemachi.dnslab.jp 	    (2001:200:132:4::2)    301.584 ms

>> Obviously, this classification has no meaning for a resolver that does
>> lookaside validation.  All DLV Records in this zone must have been
>> authenticated by you (and we all trust you, of course :-), or the
>> scheme is useless.

> Exactly. At the moment there is a large gap between trusting the unknown
> and stay unusable because there are no entries at all. My way might be to
> risky for you. That's ok. Any suggestion is welcome.

My suggestion is to establish real trust.  Yes, that's hard.  But I
can't see how you can do without.

>> Or am I missing the point and this zone should be used as a repository
>> for secure entry points from which one creates local trusted keys
>> rather than use it as a true lookaside zone?

> It serves both issues, but the main subject it to generate trust.

Right, but this is precisely what's missing right now, isn't?

>> Personally, I have come to the conclusion that I don't like it at all
>> that my cache considers the entire DNS bogus when the DLV zone becomes
>> unreachable or corrupted.

> You are free to set up a secondary. You will get notifies automatically. Of
> course invalid signatures are really bad. Because I switched almost all name
> server I admin to this zone, such a mistake will be noticed very quickly ;-)

Yes.  But this may have severe consequences.  Suppose admin X uses
your DLV zone.  An attacker DoSes all the server for this zone.  X
can't resolve any queries any more and decides to disable DNSSEC.  Now
all zones that were previously protected by DNSSEC are spoofable.

You may say that this is also possible with plain DNSSEC.  True, but
then the damage is restricted to the subtree of the zone that's being
DoSed, where as the entire DNS is considered to be a child of the DLV
zone.  DoSing the root zone is considerably harder than DoSing your
hadful of name servers.  The problem is that DLV acts a lot like the
true root zone when it brakes, but only protects very few zones when
it works (the absence of a key in the DLV zone has no real meaning, I
think, compared to a "provably insecure" zone in plain DNSSEC).

>> I'll stick to my locally configured trusted
>> keys and wait for the root to be signed.

> Of course. Do you configure the trusted keys to every of your name servers?
> How do to keep them in sync?

> You you really believe to see a signed root this life?

I don't know.  But I believe that DNSSEC will fail if it doesn't
happen.

--
Alex