Re: continued: rrsig(qtype)

[Roy Arends <roy@dnss.ec>]

On Mon, 21 Jun 2004, Paul Wouters wrote:

> On Sat, 19 Jun 2004, Roy Arends wrote:
>
> > View quick pro's of this approach:
> >
> >   NO MORE WILDCARD PROCESSING. Wildcard expansions are dynamically signed.
> >   Special processing due to (absence of) wildcards is therefor not
> >   necessary.
>
> I missed some of the previous discussion, but how does this dynamicly
> signing work? It seems from below that I would have to not only add a bunch
> of keys (per master/slave) but also have to keep those available online,
> instead of on the super-secure signing-machine. Even if this approach is
> optional, I think it would be a very bad practise to promote.

I understand your concern. Ofcourse it needs healthy key management. But
to relate your concern with current practises, assuming your concern is
that this online box may be compromised, hence a key leak:

Currently I have sig(0) and TSIG keys for axfr. If this box is hacked,
those keys leak, and I can alter data (max damage would be DoS). On
another box I have secure dynamic update running, which needs a online
key (where the damage would be data alteration).

I have concerns too about this, and I don't want to handwaive it, but
other mechanisms have online keys as well: ssh/tls/ipsec. Though they are
used in a different context with different security models on boxes which
are probably a lot less visible than an authoritative nameserver, they
have keys online.

> Also, if the nameservers needs to use crypto, it will use significant
> resources and can be easily DDOS'ed. And if hacked, they can be manipulated
> to serve changed zone data which is signed in this new "dynamic" way.

Yes, due to client/server inbalance there is a higher load on server
resources compared to clients, then with DNSSEC-bis.

Otoh, zone-size will be less, search algorithms will be faster, and
crypto-accellerators exist. Lower size for 'denial' keys improve
performance as well. Besides, the dns is scalable in width, where a
domain can have X servers behind Y ip-address behind Z names, to cope with
perceived load increase.

> Seperating the signing from the serving of data was in my view an essential
> part of dnssec security.

Then please explain why. I've seen this type of statement several times
and it belonged to the two groups of concerns: crypto-DoS and key-leak.
These statements have been used in the past, and I'm trying to relate that
to other fields, current-practise, and best practises.

The least thing the WG can get out of this is a document that states why
this is a 'very bad practise'. If there is no input for such a document,
this proposal solves a hassle.


> > Operational detail:
> >
> > It is recommended to use a unique zone-key per authoritative server. The
> > apex keyset might look as follows:
> >
> > example. IN DNSKEY ksk 000 ; key-signing-key
> > example.    DNSKEY zsk 001 ; offline zsk for pre-signing.
> > example.    DNSKEY zsk 111 ; online zsk for dyn-signing by ns1.example.
> > example.    DNSKEY zsk 222 ; online zsk for dyn-signing by ns2.example.
> > example.    DNSKEY zsk 333 ; online zsk for dyn-signing by ns3.example.
> > example.    DNSKEY zsk 444 ; online zsk for dyn-signing by ns4.example.
> > example.    DNSKEY zsk 555 ; online zsk for dyn-signing by ns5.example.
> > example.    RRSIG DNSKEY 000
> > example.    RRSIG DNSKEY 001
> > example.    RRSIG DS 001 ; pregenerated denial for DS@child
>
> This will significantly increase data transfer. If I understood you right,
> this is mandatory, since we need dynamic signing for a signed denial of
> existence.

Mandatory ? This is recommended, not mandatory. Zones decrease in size.
Negative responses decrease in size. Positive responses will include
DNSKEY RRset when there is space. Due to caching, absence of DNSKEY in a
DNS message does not automatically imply a requery specifically for
DNSKEY. If all else fail, limit the number of 'denial-keys' to 1.

> > A.4.1 Referral to Unsigned Zone
> >
> >    Referral to an unsigned zone.  The special RRSIG RR proves that no DS
> >    RR for this delegation exists in the parent zone. Not that the special RRSIG
>
> no DS RR "should" exist? You can't proof anything about the parent.

I'm talking about a referral to an unsigned zone. That is, a subzone of a
zone I am authoritative for. I'm also authoritative for the DS record, or
the absence of the DS record. With DNSSEC records, denail of DS is done by
providing NSEC for that delegation and check if the DS bit is clear. With
rrsig(qtype) it is a matter of denying DS, and since you know beforehand
what delegations are not secured, it is trivial to presign denial of DS.
My apologies if the provided text are not that clear, it was a braindump,
not a draft :)

> I personally think this causes much more headaches then it solves.

Okay.

> DNS data is public, even the .com zone. Don't contaminate the protocol
> to hide public data.

What public data am I hiding with this proposal ? I am obscuring nothing.

The problem with this discussion is that folk seem to forget that DNS was
designed as a lookup service, not a search service. It is silly to deny
that NSEC chains cause this enumeration side effect. A side-effect that
was _not_ there in DNS.

As far as 'public' is concerned: the DNS _service_ is a public service to
translate data given preknowledge.

This is why it is trivial to find my bank-account-number given a
name,address and bank, but no bank will give you all account numbers of
everybody registered to them.

This is why folks would like to restrict whois as well. A lookup in whois
is trivial, but to dump the whole database is hard. For A Very Good
Reason.

It is mere arrogance when folk blurt "if this enumeration thing is a
creating a problem with whois, fix whois". It would be like a car-dealer
saying "if this 30 feet wide truck gives a problem with roads, fix the
roads. The problem is not whois. The problem is NSEC. I can see a whole
range of issues regarding enumeration, not just whois. Given an entirely
secured tree (hey, MARID would love that), I now have a way to enumerate
EVERY existing MX record, see which is open for relay, or, as an endpoint
using a dictionary of common names, and autospam world. There is no end to
what a database of names can be (ab)used for. I'm sure you can think of a
lot more then I can.

Enumeration is a side-effect introduced by NSEC. If that is a problem,
NSEC should be fixed. That is what I'm doing. It does not hurt current
deployment, it helps folk who want to deploy DNSSEC in the future.

Roy