Subject: Re: Transition from 2535 to opt-in

From: [email-masked] (Ted Lindgreen)
Date: Fri, 7 Dec 2001 14:34:51 +0100

[Quoting Roy Arends, on Dec  7,  0:17, in "Re: Transition from  ..."]

> On Wed, 5 Dec 2001, Edward Lewis wrote:
> 
> > At 5:50 AM -0500 12/5/01, Ted Lindgreen wrote:
> > >OptIn: if OptIn, why not just forget NXT?
> >
> > The question of whether "authenticated denial is desired" has been answered
> > "yes" a number of times over the past year or so  The question has been
> > raised by the WG chair on the list and in person at London.  So it appears
> > that there is a desire to provide the service.  (Why?  I don't know)
> 
> Why ?
> 
> In a secured world I want cryptographic proof that somebank.info does not
> exist if asked for. Simply handing over an NXDOMAIN status doesn't cut it,
> anyone could give me that status, and there is nothing to cryptographicly
> verify. Would make a beauty of a DoS if it did.

Please note, that if you can substitude a secured RR by an NXDOMAIN,
you can probably substitude also other info.
Therefore, when a DOS attack is the goal, and substitution is
possible, there a plenty more possibilities to do that.
This is true whether we have DNSSEC or not. And if we have DNSSEC,
it can be done whether the zone is signed or not.

In fact, I am affraid that it is even easier to DoS a secured RR,
because just flipping any single bit in any of the accompagning
SIG/KEY chain will do just as fine as substituting the RR itself,
so the substitution possibilities only increase.

This seems bad, but please understand that DNSSEC was neither
designed, nor capable as defence against DoS attacks.

So, yes, there may be compelling arguments why and when authenticated
denial is desired, but defence against DoS attacks is not one of them.

Regards,
-- ted

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Roy Arends <[email-masked]>
Date: Fri, 7 Dec 2001 18:21:42 +0100 (CET)

> denial is desired, but defence against DoS attacks is not one of them.

I keep hearing that statement over and over all over the place in several
ways, shape and form. "DNSSEC was not designed as a defense against DoS
attacks". When I say "beauty" of a "DoS" attack, I implied one can
actually (ab)use DNSSEC in an almost perfect way to simply kick a domain
of the planet if one would do away with authenticated denial. Note that
this is a far more efficient (several orders) of DoS attack then simply
compromising a record on the fly.

If the "DNSSEC was not designed as a defense against DoS attacks" is used
as a general statement, why aren't NXT and SIG generated on the fly ?
EXACTLY, to make sure the system will not be used against a DoS.

And why is there DNSSEC in general ? To defend against spoofs, poisons and
other DoS attacks.

It is all in the eye of the (secure) resolver. It wants some cryptographic
proof, a signed record, something to verify.

Roy Arends
Nominum

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 07 Dec 2001 13:58:32 -0500

> > denial is desired, but defence against DoS attacks is not one of them.

This position taken to an extreme would encourage us to engineer a
"please crash" request into every protocol.

It would be wrong to lump all denial-of-service attacks together into
a single category -- there are many different sorts of attacks which
could cause denial of service.  Some are easy to defend against, some
are hard.

IMHO, the way to go is to engineer protocols (and implementations) to
be robust against low-packet-rate denial-of-service attacks (such as
forged NXDOMAINS and the "classic" SYN flood), while efforts like
itrace provide tools to allow network operators to deal with the
high-packet-rate attacks.

						- Bill

---

From: Derek Atkins <[email-masked]>
Date: 07 Dec 2001 17:48:31 -0500

> EXACTLY, to make sure the system will not be used against a DoS.

Well, partially.  They are not created in real-time because the data
is quazi-static.  Why re-sign the same data over and over when you can
sign it once and re-use the signature?  Also, creating signatures is
an _expensive_ operation.  It was even more so 5+ years ago when 2535
was being written.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Roy Arends <[email-masked]>
Date: Sat, 8 Dec 2001 00:19:25 +0100 (CET)

> an _expensive_ operation.  It was even more so 5+ years ago when 2535

You're right and there is also the private key on an online machine issue.
All these arguments make a case for NXT+SIG to be generated in advance.
The argument (DoS) I made came up when I was looking at alternatives for
storing NXT+SIG's.

Regards,

Roy Arends
Nominum

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 07 Dec 2001 16:26:17 -0800

> > an _expensive_ operation.  It was even more so 5+ years ago when 2535

well, the protocol as it sits right now (but not for long!) was designed
with the idea that dynamic calculation would be too expensive.  in other
words the reason we precalc these sigs is because we can, and the reason
we can is because we thought we would have to so we designed it that way.

> The argument (DoS) I made came up when I was looking at alternatives for

does anybody other than me think that if we're still addressing issues at
this fundamental level five+ years into the project, that we're just doomed?