Subject: Re: Proposal to fix NSEC

From: Derek Atkins <[email-masked]>
Date: Thu, 20 May 2004 10:45:16 -0400

Peter,

Peter Koch <[email-masked]> writes:

> Bob Halley <[email-masked]> wrote:
>
>> The problems with online signing are:
>> 
>>         It's a CPU burden for the authoritative nameserver.
>
> Yes, but the operators in question (TLD registries) should be able to deal
> with this.

I don't think you understand what level of CPU burden online signing
can be in the face of unauthenticatd queries.  It's a DoS attack
waiting to happen.  Turn this "feature" on in your DNS servers and I
can bring your server to its knees without even trying.  It's very
simple: I send a string of random requests to your server for random
(non-existant) hosts in your authoritative zone.  To make sure you
can't block this easily at your firewall I spoof the sender address (I
don't care about the responses anyways).

Even if modern TLD CPUs can handle 10,000 RSA encryptions per second
(my laptop tops out at around 2,000 with full-bore CPU usage), that
just means I need to send you 10,000 requests per second.  That's
about 10mbps (probably even less).  Not too hard to achieve.  Note
that my 2000/s is full-CPU.  You need a good deal of CPU to actually
perform the DNS query/response, so that reduces the number of actual
RSA operations possible.

The problem is that it's just too prone to DoS attacks....  Which is BAD.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 May 2004 21:51:08 +0100

Peter Koch wrote:

>>        You must trust your slaves enough to give them the right
>>        to make signatures.  In the standard DNSSEC model, a
>>        rogue slave can deny service, but it cannot generate
>>        authenticated zone content.
> 
> 
> Most TLDs already have all their nameservers under their very own control
> (although not necessarily on a physical level). So betrayal by 2ndary isn't
> a problem. For cases where one of the servers is compromised, DoS is possible
> even with DNSSEC because an attacker would be able to provide for forged
> signatures. The risk of forged entries can be reduced by using different
> keys. The offline key would be used to sign RRSets, securing positive responses
> (mostly DS RRs). The online key could be used to sign online NSEC RRs to
> be generated on the fly (and pointing at some uncritical, maybe not even
> existing name). It's just that I don't see an opportunity to signal this
> distinction at the moment.

If you were going to do this, it would make more sense to simply sign a 
denial of the existence of the particular domain, rather than messing 
with NSEC records. If you had a signed denial, then the easy way to 
signal it is to have an RR that is specifically for that purpose (that 
is, when you receive a NOTHISDOESNTEXIST RR you expect it to be signed 
with the special key used for that purpose alone).

This is another solution I didn't dare suggest!

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 23:19:43 +0200

On May 20, 2004, at 3:06 PM, Peter Koch wrote:

> The offline key would be used to sign RRSets, securing positive 
> responses

Good idea...

There is no reason why one part of a zone cannot be signed with zone 
signing key 1 and another
signed with zone signing key 2. There is no need for signaling.

This is an essential property to be remembered during key rollovers 
when there may be several RRsets from a zone living somewhere in a 
cache that have signatures made with valid keys. The zone operator 
needs to provide the public key material of both the keys during the 
rollover.

Note also that if you minimize the signature validity time on the apex 
keyset you reduce the useful lifetime of the a compromised key.

--Olaf
  (no hats)