[dns-wg] Just another lookaside zone

On Wed, 8 Feb 2006 17:35:44 +0000 (UTC), Lutz Donnerhacke <lutz at iks-jena.de> said:

> * Alexander Gall wrote:

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

Yes, that's what I meant.

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

Surely you don't mean to say that you remove a DLV RR when it no
longer authenticates the DNSKEY RRset.  Or are you?  I might
misunderstand what you mean by "keep the network running", so I'll try
to rephrase what I wanted to say.

DNSSEC doesn't tolerate mistakes that break the chain of trust because
it can't be distinguished from an attack.

Now, it would be perfectly fine for an end user to decide for himself
whether he wants to accept the bogus information or not, but, of
course, that's impossible without an API or DNSSEC support in the stub
resolver which allows for a local policy.  In any case, DNSSEC must
provide this information (i.e. that the delegation is broken).

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

That would be really bad.  I tried to argue that removing the DLV
must not be done either.

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

Sorry, I didn't realize that the main purpose of your daily job was
checking for rollovers.  We are in violent agreement here.

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

I'm talking about OOB methods, of course (like
<https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt>).

> 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 know that PKIs are not what they were promised to be, but they are
not completely worthless either.  I try to maintain a level of trust
that I feel comfortable with.

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

Um, I prefer an unsigned zone over one whose signatures I cannot
trust.  What is the improvement there?

[...]

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

As I said, it should be up to the user to decide whether he want's to
use the information or not (just like he can chose to accept a bogus
SSL certificate, which can be perfectly harmless, too).  That's not
the point, though.  Signatures are completely useless without trust.
It's even worse because they can give the casual user a false sense of
security.  I'm sure you know that better than me.  Without trust, this
whole excercise is essentially a test of DNSSEC implementations.
That's fine, too, but it needs to be stated clearly.

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

Having all users of the DLV zone become a secondary doesn't scale
(because of the size of the NS RRset and possibly the load on the
master).  

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

I think this would be equivalent to the following.  Let people
download a signed file with the keys and install them as trusted keys
in their servers (the key that signs the file would have to be
authenticated just like the one for the zone dnssec.iks-jena.de).  If
all the information is local anyway, DLV would then just be a
complicated way to check a local trust anchor.  Using an established
mechanism (AXFR) to distribute the zone is nice, but it's not a
necessity (oops, I'm starting to sound like Dan Bernstein ;-)

[...]

>> 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'm not talking about unreachable servers but about getting a prove
that a particular name does not exist in the DLV zone.  What does it
mean?  It's the same as not having a local trust anchor configured for
the zone, but it does not constitute a prove that the zone is
unsigned.  So, you have less information about the zone than when you
get prove from the parent zone that no DS RRset exists.  Essentially,
you don't learn anything about zones that are not in the DLV zone, and
yet, all of these zones are considered compromised when the DLV zone
is broken.  This trade-off is what bothers me the most.

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

This is easy.  I centrally maintain a BIND configuration snippet for
the "trusetd-key" clause and push it to my caching servers with scp (I
also do some failsafe checking that the config is OK before doing a
"rndc reconfig").  It's simple and reliable.

The situation is a bit like with the now deprecated A6 RR.
Renumbering your own DNS zones is easy.  All you need is a bit of
discipline and a perl script.  You don't need A6 for that.  The true
value of A6 would have been renumbering across administative
boundaries.  Similarly, DLV is only needed if you use a "regular" DLV
zone.  If everybody keeps a local copy of the zone as you suggest, DLV
is just overhead, as I tried to explain above.

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

DNS just happens to be a global infrastructure :-) Idon't think it
would have worked if it had started as a heap of disconnected pieces
patched together by a mechanism that doesn't scale.

If it were just a technological issue, I'd be all for it and use any
hack to get it going (I should know, because I'm a long-term IPv6 and
multicast user ;-) Unfortunatley, I don't think this will do much good
if security is the main objective.

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

Yeah, I hadn't realized that RIPE NCC had signed 6.0.1.0.0.2.ip6.arpa
until I spotted the entry on your site.  Our zone 195.176.in-addr.arpa
has been securely delegated since November.

--
Alex