[dns-wg] Just another lookaside zone

* Alexander Gall wrote:
> 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 ;-)

Of course, I'll remove the DLV entries for chained zones. These resolvers
need to be fixed, not the zone. Give me a day.

> On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke <lutz at iks-jena.de> said:
>> 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?

After the change tomorrow, the DLV entry will be inserted to keep in touch
with the changed zone. It will dismiss, if the parent reflects the change.

Such behavior will only happen, if the new key is signed with a valid old
one. It's not required, that the new key is used for signing in this very
moment. Might only be happen if the rollover period is too short or if the
client do not notify the parent at all.

Oh, the parent might also simply drop the DS record. In this case the
formerly verified DNSKEYs are used to generate DLV entries.

I'd should display an error indicator due to broken chaining.

> 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.

On usual rollover, all keys are valid as long as there exists a valid chain
to each of them. Valid keys are retained for chain breaks. So normal
rollover does not harm.

> In all other cases, you *must* keep the broken chain.  This will render
> the zone bogus, but this is precisely what should happen.

IBTD. From the operational point of view the error in chaining is much more
likely to be an mistake, than a thought decision. The new DNSKEYs has to be
signed to be accepted, so there must exists a operational action to break
this chain while staying in the DLV. I prefer to keep the network running.

DNSKEY changes without a trust chain from already trusted entries are not
accepted, so classical attacks will not cause the DLV to show up the
attackers key as valid.

>> 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.

This case will change tomorrow to only notice the existance of the signed
sub zone. Usually new entries are added as islands.

>> 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)?

Apart rollovers? I try to detect legitimate rollovers. But there are other
kinds of key changes, which are detected in this way. As long as they match
the rollover procedure, I try to keep in touch. OTOH it's a simple
"reachable" check from outside.

>> 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.

Please let me smile. First: There is no canonical way to get the DNSKEY
information automatically. Second: If the zone is under attackers control,
each validation can be forged.

You might refer to SSL certificates, but I do not trust most of those CAs.
We are in the CA bussiness since about nine years. I lost all my illusions.

> I think you should not accept unauthenticated SEPs at all.

If I do not accept it, the zone can only be used unsigned.
What a security improvement!

>> 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 :-)

I do not claim my assumptions as true. If you can reach those zones, the DLV
entry might be useful. If you can't reach those zones, they do not harm you.

>> 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.

It's very possible to be too paranoid. Unrelated and uncheckable information
can be considered true without any damage. That's why I include it.

>> 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.

If X set up a secondary (as recommened), the DoS does not harm unless the
zone times out. In this case X get's a notice from its own name server and
can use the secondary data as primary, if necessary. But if X has a minimal
interest in his infrastructure, he will notice such a DoS of a "partner"
much earlier. If the zone times out due to such an attack, it's very likely
that my company does not exists anymore. So X has to contact an other source
anyway.

> X can't resolve any queries any more and decides to disable DNSSEC.
> Now all zones that were previously protected by DNSSEC are spoofable.

X has a long transition period to change.
X is not required to disable DNSSEC at all, because backup data is available.

> 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.

Ack.

> 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).

Nack. Provably insecure is not caused by unreachablity of a name server.
It is caused by reaching the server and get a signed answer.

>>> 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?

I'm really interested in an answer to this question,
because this was the basic reason to set up the lookaside zone.

>> 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.

Global requirements are the main reason to fail projects. It would be nice
to have, but it's unlikely. So we have to deal with.

BTW: Congratulations to your signings. Your zones does appear last night in
my monitoring and I'm very happy to see that deployment increases.