Subject: issues with draft-ietf-dnsext-dnssec-trans-00.txt

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Jun 2004 17:18:11 +0100

"2.1.1.4 Cons

    Unbalanced cost is a ground for DDoS. Though this protects against
    enumeration, it is not really a path for versioning."

This should also mention the security risk of the requirement for an 
online key.

"2.1.2.2 Limitations

    There are no technical limitations, though it will cause delay to
    allow testing of the (currently unknown) new NSEC interpretation.

    Since the versioning and signaling is done inside the NSEC RR, future
    methods will likely be restricted to a single RR type authenticated
    denial (as opposed to e.g. NSEC-alt, which currently proposes three
    RR types)."

Note sure I understand this - the presence of v2 of NSEC would signal 
that there are also NSECINFO and EXISTS records, wouldn't it?

2.2.2.4 Cons

Spello: role -> roll

"3. Conclusion

    The authors recommend that the working group commits to and starts
    work on a partial TCR, allowing gracefull transition towards a future
    version of NSEC. Meanwhile, to accomodate the need for an
    immediately, temporary, solution against zone-traversal, we recommend
    On-Demand NSEC synthesis."

We (that is, Nominet) can't at present imagine how we could deploy this. 
The problems we see are:

a) Invitation to DoS us, suggesting we'd need to investigate crypto 
offload devices.

b) Changes to software required, and hence a long period of validation 
and testing.

c) Exposure of private keys.

This sounds no easier to deploy in practice than NSEC2 would be, even if 
it didn't have problems that appear to make it unworkable in any case.

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

--
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: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 22:02:16 +0000

> > Which you could add are of particular concern where not all
> > secondaries are under the same administrative control as the primary
> > (whereas with DNSSEC-bis this is irrelevant)
> 
> I think this point should be emphasized more.  With the solution
> dnssec-trans appear to propose, it is not enough to transfer a zone
> file to a secondary, you must also transfer the private keys to all
> secondaries, and keep the keys synchronized.  That is not a trivial
> problem.

and yet, this is a subset variation on what the ihren-manning-kolkman
"perl goo" does, and so this approach ought not be discounted on the
sole basis of its nontriviality.  it's possible that many nameserver
administrators will already be doing some kind of outofband keyrollover.

> It is complicated further by considering the lose trust zone
> administrators often have on the organizations running their slave
> servers.  Typically they do not have any secure communication channels
> between them.

actually, typically these days, they do have such a secure channel, in
the form of a shared TSIG key used to control/authenticate AXFR/IXFR.
(an upcoming tool from isc leverages this trust relationship with what
we're calling a "metazone", which is why your statement caught my eye.)

---

From: Alex Bligh <[email-masked]>
Date: Thu, 10 Jun 2004 23:28:41 +0100

--On 10 June 2004 21:53 +0000 Paul Vixie <[email-masked]> wrote:

> for operators of enterprise zones this is a practical alternative.  for
> operators of delegation-only or delegation-mostly zones where the subzones
> are held by "registrants", this alternative is only practical if most of
> those registrants are happy to be disconnected from dnssec in this way.

Sure - I wasn't make a policy point, I was just making the point that
draft-ietf-dnsext-dnssec-trans-00.txt omitted this possibility. Clearly it
has both pros (no alteration to -bis, implementation is hardly difficult!)
and cons (um, no DNSSEC functionality).

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 09:37:03 +0100

Jim Reid wrote:

>>>>>>"Ben" == Ben Laurie <[email-masked]> writes:
> 
> 
>     Ben> Note sure I understand this - the presence of v2 of NSEC
>     Ben> would signal that there are also NSECINFO and EXISTS records,
>     Ben> wouldn't it?
> 
> Not necessarily. Who can say now what NSECv2 will finally look like or
> predict how many new RR types it'll need?

I don't see why that matters - a resolver that understood NSECv2 would 
also understand the other RR types, and one that didn't, err, wouldn't.

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 15:23:49 +0200 (CEST)

On Fri, 11 Jun 2004, Geoffrey Sisson wrote:

> From: Roy Arends <[email-masked]> writes:
>
> > The cost of crypto-accelerator cards are a tiny fraction of the overall
> > DNSSEC deployment, support, production and management cost.
>
> Even with fast crypto hardware, isn't there still a problem of
> significant asymmetry?  Normal operational loads could be easily
> accommodated, but a malicious party should have no problem generating
> sufficient levels of queries for non-existant domain names with the DO
> bit set to overwhelm any practicable level of signing capacity.

There are first other ceilings (like bandwith, server performance) to
overcome if one suspects a possible crypto DDoS. This implies that a
simple non-crypto DDoS is just as easy to deploy, and the asynchronous
cost argument (for this particular use) disappears.

Roy

---

From: [email-masked] (Geoffrey Sisson)
Date: Sat, 12 Jun 2004 00:41:43 +0100 (BST)

> cost argument (for this particular use) disappears.

True . . . if plausible crypto acceleration solutions exist which are
capable of generating 40,000 NSEC RRSIGs per second, then admittedly
DoS attacks exceeding this rate would be close to exceeding other
operational thresholds.  With luck, the rate of improvement in
respective capabilities (crypto acceleration, bandwidth, server, etc.)
will not adversely affect this balance before -ter is deployable.

Regards

Geoff

---

From: Don Stokes <[email-masked]>
Date: Tue, 15 Jun 2004 15:18:31 +1200

Simon Josefsson <[email-masked]> wrote:
>Of course, being able to spoof that something doesn't exist is worse
>than one might first assume; missing MX records can redirect e-mail.

MX is the obvious case where spoofed authenticated denial could be used
in a non-DoS attack.  Anything that has some kind of fall-back will be
vulnerable, including use of search lists for partial name lookups,
low-priority SRV records etc. 

-- don