Re: continued: rrsig(qtype)

[Roy Arends <roy@dnss.ec>]

On Mon, 21 Jun 2004, Paul Wouters wrote:

> On Mon, 21 Jun 2004, Roy Arends wrote:
>
> > Yes, due to client/server inbalance there is a higher load on server
> > resources compared to clients, then with DNSSEC-bis.
>
> And the only reason for this is the supposed secret/patent/trademark state of
> the .com zone? I wish the CC:TLD's would just go on without Verisign.

This is nonsense. I have no problem getting .com, de, nl, se or any other
TLD (yet). I just asked for it. I got it. No blood, nada.

> > Otoh, zone-size will be less, search algorithms will be faster, and
> > crypto-accellerators exist.
>
> That won't help against a ddos attack though. It will always be cheaper to
> send the queries then to answer them.

Currently, without DNSSEC, DDoS are feasible. No problem. If you can
increase signing speed to be as fast/faster then serving, we're done.
Given a well-known imp can do about 4K in res/sec and cryptocards are
available that can sign ten times faster then 4K...

> > 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.
>
> Adding X KEYs and SIGs for every authorative nameservers.........

That (optional (not mandatory) key+sig per response) is still smaller then
2 NSEC + 2 SIGs per response.

> > > 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.
>
> Because of the path of trust relationships between servers. You want
> a severe limitation on the acess to modify data, yet you want to be
> liberal in access to signed (therefor more or less readonly) data.

There is severe limitation on the access to modify data: NONE.
The DNS service itself is public. so there you go.

> > 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.
>
> To me, the security of seperatnig signing and serving is worth more then the
> reduced traffic. DNS makes up about 0% of my traffic (or an endusers traffic)

You are manipulating the argument. I wrote this in reaction to your
argument:

      > This will significantly increase data transfer. If I understood

You're dismissing your own argument.

> > 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.
>
> Sure. but
>
> 1) Is this worth all the extra drafts and rounds and IETFs and the above
>    mentioned security implications?

Obviously...

> 2) Go ratelimit your queries if you are concerned about walking.

Why do that if we can 'fix' the protocol.

> 3) Go publish the list of domains in TLD's and people will stop walking the zones.

That is done, but you have to ask. That is called 'good faith' not
'god-given-right'.

> NXT walking is a political problem, not a technical one. Do we really want to
> wait deploying DNSSEC until some major distributed dns pollution scam happens?

Ah, now I see your fear. Rest assured. This proposal is for dnssec-ter,
not dnssec-bis. The current docs will go as is, with some minor editorial
tees and dots. You'll have your dnssec.

> > 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.
>
> They are not refusing for technical reasons, but commercial reasons.

No. They are prohibited by law.

> > 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.
>
> With 4 year olds having 350.000 zombie machines available, "hard" gets a new
> meaning. What is the problem of harvested whois data? The most common issue in
> the past was "spam". Well, with the dictionary based spam attacks out there
> this has become irrelevant.

Is spam past ?

> > 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.
>
> So you are saying NXT walking is a problem because people will use faults in

No. I'm saying that NSEC introduces a new service that _WILL_ be used,
while that new service was not a design goal. Some, like Ben Laurie and
Simon Josefsson have introduced a possible solution. I am now introducing
a possible solution.

> > 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.
>
> Anything not getting DNSSEC into an RFC is a problem.

This does not delay DNSSEC. You are crying wolf premature.

> Postponing DNSSEC for another year by fixing this corner case of abuse
> is going to give me a LOT more spam then the amount of spam I would get
> when DNSSEC is deployed and people can start using things like SPF
> records.

See above.

> You know, the Catholic Chucrch had similar problems in the past electing a new
> Pope. the process would take weeks, months or even years. They invented the
> "Conclave", a protocol still in use today, whereby all Cardinals involved in the
> election process are locked up in the Sistene Chapel, and they can only come out
> when they have elected a new Pope. Sometimes I think the IETF should adopt this
> process. Perhaps I should write an RFC for this :P

Do that.

Meanwhile, I'd like to ask you to comment on the technical merits of this
proposal. Not handwaving, dismissing, rediculing, politicizing issues that
others might have with side-effects introduced by NSEC. If you're on a
stretch, trying to gain some momentum by stating hollow irrelevant
lunancies, polarising discussion for mere self interest, FUD or by
paranoia, this is the wrong forum. Otoh, if you're really interested in
volunteering to write a draft, please state that to the dnsext-wg chairs.
There is always a shortage of volunteers.

A few disclaimers:

This proposal does not delay DNSSEC deployment.
This proposal makes use of DNSSEC-ter and DNSSEC-trans.
This proposal does not delay any current DNSSEC-draft.

Promise.

Roy Arends