[dns-wg] Just another lookaside zone

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

No, I cleaned up the verification step so that DLVs are updated using the
following parameters:
  
  Keys : valid, signed DNSKEYs
  DSs  : valid, signed DS parent entries
  Old  : DS entries from the active DLV zone
  
If Keys and DSs exists, no DLV is generated.
If Keys exists, DLVs are generated.
If DSs exists, DLVs are generated for 30 days.
If Old exists, DLVs are generated for 7 days.

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

On rollover it's very likly to do not get the parent updated or the parent
restores an old entry by accident. In this case, I generate DLVs based on
validated information. I can't see what's wrong with it.

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

Please explain why and how a delegation can break. This will clarify why I
prefer to keep former validated data active.

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

The main purpose of providing a DLV zone is to keep this zone in sync with
reality. I do not expect all DNSSEC opertators to update there keys on my
website. So I have to do it myself.

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

This page is used. On most other cases there is no way to be sure.

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

Please explain how a PKI can be used, if the common ones are not trustworthy
and most DNSSEC operators does offer there keys on various unstandardized
ways. I can't see any automatic check usable.

There are 418 island of trust in the DLV zone at the moment. Please try
and check some of the unknown yourself.

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

If the keys are correct, you gain a valid signed zone.
If the keys are wrong, you can be fooled about the zone content.
If the keys are missing, you can be fooled about the zone content.

The attacker has to modify the zone in order to get it listed in my list.
If the attacker had modified the zone, the unsigned information are ...

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

So you need a checklist with about 500 entries now customizable for each user.
Not my task. Sorry.

> Signatures are completely useless without trust.

No signatures are better?

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

DNSSEC does not provide security in the common sense. It protects DNS to
intermedeate changes. This can be achived.

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

I do not include them into the zone. They get notifies. That's all.

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

Of course. This is the distribution step I mentioned. It's easier to
maintain using a DLV zone, than synching a lot of keys. Do rollover
detection on those keys automatically and you end up in methods I use.
If you do not maintain the key list, it's useless.

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

Nothing. The zone can't be checked even if it is signed.

> but it does not constitute a prove that the zone is unsigned.

DLVs does not prove the signedness of a zone.

> So, you have less information about the zone than when you
> get prove from the parent zone that no DS RRset exists.

If the parent has DS records, the zone is not in the DLV. The parent is.

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

DLVs are a distribution medium. If the distribution of your key files
breaks, you get an equivalent disaster.

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

I do not like to maintain a list of servers to push configuration to. Often
I even can not do this because those machines are not mine or not reachable
for typical distribution mechanisms.

How many entries do you maintain in your trust key file? Are they still valid?

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

Setting up an hidden secondary is not an overhead.

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

IPv6 either. Do we have it all over the world?

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

I assume it scales. YMMV.

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

I do think of DNSSEC deployment as a technological issue. Did you notice,
that dnssec-deployment.org is not signed ;-?

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

Great. An now you will notice, that some entries are going dead ...