Subject: Re: NSEC+ and NO

From: [email-masked]
Date: Wed, 26 May 2004 16:37:48 +1200

Olafur Omundsson?= <[email-masked]> wrote:
>6.1
>	Are any TLD's willing to go on the record to say NSEC zone
>		walking is a
>			non-issue
>			show-stopper

I'm not the policy guru for NZ, just the guy who gets asked DNS stuff.
However, it's very clear to me that there would need to be a major
change in view among NZ registry stakeholders for NSEC to be accepted
because of the zone walking problem.

The ability to walk the zone would have to viewed in the same light as
for zone downloads, given that the for the most part, the same policy
issues are exposed.  It's possible that the rate of such walking could
be restricted in the simple cases, but I don't think I could put my hand
on my heart and say that such throttling would stop those even mildly
determined to get a copy of a zone, nor that it would not potentially
negatively impact the performance of the name servers in responding to
legitimate queries.

Current zone transfer policy[1] is basically "no zone transfers unless
authorised and conditions met". The new draft policy[2], likely to be
accepted very shortly, is more restrictive, basically denies access to
zone files unless an "exceptional reason" for access to the zone can be
demonstrated.  

There is a clear trend towards becoming more protective of the registry
database, and the index to the WHOIS data it represents.  

That said, DNSSEC is quite clearly on the NZ registry radar; we would
very much like to be on the leading (but perhaps not bleeding) edge of
DNSSEC deployment.  

Getting a little more pragmatic, I think the real question is, can we
have our cake and eat it too?  Or, can we break NSEC walking without
breaking NSEC?

Consider...

Authenticated denial relies on there being am authenticatable "space"
between each record, thus if I have:

	a.example.	NSEC	c.example. ...
	c.example.	...

then I know that there are no records between a.example and c.example. 

But if I instead inserted:

	a.example.	NSEC	a_.example.  ...	
	a_.example.	NSEC	a__.example. ... ; booby-trap
	a__.example.	NSEC	c.example.   ...
	c.example.	...

What if an explicit query to a_.example. triggered some kind of
defensive response, such as a complete refusal to return the NSEC
record?  In this example, because of the third NSEC, you would never get
the booby-trap record except as the result of an attempt to walk the
NSEC chain.

-- don

[1] http://www.dnc.org.nz/content/zone_transfer.pdf
[2] http://www.dnc.org.nz/content/proposed_new_zone_transfer_policy.pdf

--
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: Peter Koch <[email-masked]>
Date: Wed, 26 May 2004 09:42:49 +0200

> the booby-trap record except as the result of an attempt to walk the

"NSEC" walking would usually not be done with explicit queries for NSEC RRs
(because that's too easy to answer with REFUSED, since there's probably no
need for those queries) but by asking for "random" names and interpreting
the NXDOMAIN responses (and the NSEC RRs therein). So, one wouldn't ask for
"a_.example." anyway but for e.g. the next name after "a_", say "a__".
Now you could protect this name by the booby-trap, but then I'd ask for "a___"
and the more traps you have the lesser NXDOMAIN responses you can really
support with NSEC, which sooner or later would hit an innocent requestor
who's not walking but just mistyped a domain name.

-Peter

---

From: Alex Bligh <[email-masked]>
Date: Wed, 26 May 2004 09:57:44 +0100

> the booby-trap record except as the result of an attempt to walk the

This only works if the querying person cannot distinguish the booby-trap
records (or those leading to them) from the real records. But you have
to (as you have illustrated) put your booby-trap records as close
as possible to the records themselves. For example if the records are:
	string.example	NSEC	string_.example
	string_.example	NSEC	string__.example ; booby trap
	string__.example	NSEC	struth.example
	struth.example...

then when you get the boobytrap result (for string_.example) you
just look up string_zzzzzzzzzzzzz.example instead, which will give you
a non-exist pointing to struth.example.

On a more theoretical level, what you are trying to do is introduce
small segments of the space "between" names that do not return useful
non-existence proof. You want to make that space as small as possible
in order that non-existence proof works elsewhere. But that makes it
trivially easy to ask instead for a name outside that small space but
in the larger space before the next "real" name.

Alex

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 26 May 2004 11:34:17 +0200 (CEST)

On Wed, 26 May 2004, Alex Bligh wrote:

> records (or those leading to them) from the real records.

note that the "person" will most probably be some sort of program.

> a non-exist pointing to struth.example.

you do not know if there are zero or more boobytraps in between.

this is in no way failsafe, but could probably be used to stop simple 
walking and plain enumeration by guessing labels. I think it should be 
explored further by those who might need it.

 	jakob

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2004 14:03:41 +0000

> need for those queries) ...

actually i was planning on using ANY queries starting at @, the answers to
which would include NSEC.  that way i can gather all the data in the same
pass where i gather all the names.

in the scenario, booby traps would be quite effective.

the trouble with booby traps is, since udp source addresses are spoofworthy,
it would possible to make an authority server generate and hold a huge amount
of state just by forging a boobytrap-o-gram from a zillion different addresses.
if there's a quota, you can make them overrun it, thus making room for your
real zonewalk queries.  if there's no quota, you can make them run out of
state-memory.

---

From: [email-masked]
Date: Thu, 27 May 2004 14:05:18 +1200

Alex Bligh <[email-masked]> wrote:
>non-existence proof. 

That's exactly what I'm suggesting.

>                      You want to make that space as small as possible

Is that actually the case?  Do we care about queries for domains that
don't exist?  Is there a problem with the following:

	a.example.	NS	ns1.isp.com.
			NS	ns2.isp.com.
			DS	...
			RRSIG	DS ...
			NSEC	a_.example. NS DS RRSIG NSEC
			RRSIG	NSEC ..
	b.example.	NS	ns1.isp.net.
			NS	ns2.isp.net.
			NSEC	b_.example. NS RRSIG NSEC
			RRSIG	NSEC ...
	d.example.	...

That is, if someone asks for foo.a.example with DNSSEC, they'll get a
referral with a signed DS record; if they ask for foo.b.example, they'll
get an referral with a signed NSEC record that securely marks the
delegation as insecure.

If they ask for foo.c.example, they'll get an NXDOMAIN.  Which is what
they'd have gut if DNSSEC wasn't in the picture.

In essence, only the parts of the zone containing the live domains
support authenticated denial; that is, from a registry's point of view,
we don't really care about what happens to a domain that doesn't exist
anyway, as long as we can give an authenticated "here is the DS record
for this delegation", or an authenticated "this domain doesn't have a DS
record".

Is this a compromise that will work for TLD registries?  Note that I'm
really focusing on registry domains; these have fairly specific
requirements (.museum notwithstanding).

-- don

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 04:04:20 +0000

> ...

this isn't practical.  if the .org people did this, then isc.org would be
subject to downgrade attacks wherein an attacker could insert unsecured
responses into the transaction stream making folks believe that isc.org
did not exist, and the querier would not be able to tell that it had been
spoofed.  i want both positive and negative responses about my parent domain
to be signed and verifiable.

> Is this a compromise that will work for TLD registries?  

i hope not.  not for any registry of which i'd like to be a customer, anyway.

---

From: [email-masked]
Date: Thu, 27 May 2004 19:49:54 +1200

>to be signed and verifiable.

Can you explain to me the difference, from a security enabled resolver's
point of view, between the following three cases:

(1) A non security enabled name server returning NXDOMAIN for a name
that doesn't exist;

(2) A security enabled name server returning NXDOMAIN for a name that
doesn't exist (but which would return signed data or an appropriately
signed NSEC if the name did exist), as per my previous post; and

(3) A man in the middle intercepting a request and responding to it with
NXDOMAIN.

-- don

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 May 2004 13:56:55 +0200

> they'd have gut if DNSSEC wasn't in the picture.

If I got that right you're in essence suggesting that the "pointer part"
of the NSEC RR be optional. Instead of having it point "somewhere", I'd use
the target for explicit signalling of this feature, e.g. let it point to
the root domain (yes, that would make a problem in ".") or the owner name
itself (which makes problems in "empty" zones) or abuse the NSEC 'bit' in
the RR list.

However, this would open *all* delegated domains, whether secure or not,
to a DoS because someone could intercept an answer and substitute the
referral by an NXDOMAIN response. Since those are unprotected under this
scheme, there's no way to tell whether or not the delegation really exists
(the answer would have to carry some witnessing of the "NSEC doesn't use
pointer" feature, e.g. per the NSEC of the zone [*])

But, since SERVFAIL or REFUSED could always be spoofed (although usually
not cached), there is already a risk of DoS even with authenticated denial.
The quality of both attacks is different (I just cannot reach, say, a webserver
or I may be made to believe a whole organisation ceased to exist - or at least
lost their domain name) but the quality of this difference could be and even
may have been discussed.
The 'threats' draft and the DNSSEC docset don't discuss this kind of "negative"
response (and I'm not sure they should).

-Peter

[*] As was said earlier in this thread, these "per zone" features have
    their own difficulties because you don't necessarily know the enclosing
    zone, so a delegation could be deeper inside a zone than one level,
    e.g. "sub.sub.example" in "example", but per this feature it could be
    required to use one-sublevel-only delegations.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 14:06:11 +0000

> (3) A man in the middle intercepting a request and responding to it with

assuming that case (2) does not include an NSEC covering the query name,
then among those three there is no visible difference from a validator's
point of view.  however, there's a fourth case, which i'm interested in:

  (4) A secure negative response including a covering NSEC, signed with the
  zone's key, indicating the nonexistence of the name.

if a validator has a reason to expect security, such as a static trusted-key
for the zone or a parent DS learned during delegation, then cases (1), (2)
and (3) would all be treated as a possible instance of (3), and only case
(4) would be taken seriously or considered to be useful for subsequent
processing (such as giving up on the forwarding of email to that domain, or
giving up on contacting a jabber server at that domain, or whatever.)

in your previous post you proposed a signalling method that would make us
treat all negative responses as temporary failures.  that's not a value add.

---

From: [email-masked]
Date: Sat, 29 May 2004 23:06:22 +1200

>treat all negative responses as temporary failures.  that's not a value add.

No, it isn't.  But it still leaves us with a problem.  

It will be difficult to sell DNSSECbis to registries, especially ones
such as NZ and UK that have wide, largely non-technical stakeholder
bases, for reasons that are wider than the immediate technical validity
of DNSSECbis, but are nevertheless neither invalid nor entirely
non-technical, if the zone walking problem is not addressed.

I see a number of ways forward with this from a registry point of view:

(1) Deploy DNSSECbis regardless.  Don't care about the stakeholders.

(2) Wait for DNSSECter to come along (be it NSEC2 or some kind of NO).

(3) Deploy DNSSECbis with some level of degradation to either disable
zone walking or make it sufficiently difficult (and therefore uncommon)
that registry managers can reasonably go after perpetrators by other
means.  Maintain that level of degradation until DNSSECter is available,
and switch at the first opportunity.

Option (1) is not going to fly in NZ at least, and from what I've seen
on this list, not in UK or DE either.

Option (2) is the safest choice.  But it's not going to help advance
DNSSEC.  I can't speak for other registries, but in NZ, there is a
stated desire to move forward with DNSSEC as far as it is compatible
with other policies and requirements.

Which leaves option (3).  To which the question is: how far does DNSSEC,
or at least NSEC, need to be "broken" to prevent zone walking.  I put
two options to the list in earlier posts; (a) one where the links
between names are broken just a little, the other (b) where the NSEC
links are completely broken.

(a) retains authenticated denial for all but a few highly pathological
cases, but appears trivial to defeat.  (b) loses authenticated denial
for all non-existent domains, but will reliably prevent zone walking.

Is there a variation on (a) that can't be trivially defeated (my
preferred option); or do I have to deploy (b), which still buys us
secure delegation and authenticated denial of secure delegation for
domains that do exist.

Or should I just throw my hands up in despair, say, "it's too big, too
slow, and we can just use end-to-end authentication & encryption
anyway", as I'm sure the folks peddling PKI & CA services would just
love me to?

-- don

---

From: Roy Badami <[email-masked]>
Date: Sat, 29 May 2004 14:20:12 +0100

>>>>> "don" == don  <[email-masked]> writes:

    don> Which leaves option (3).  To which the question is: how far
    don> does DNSSEC, or at least NSEC, need to be "broken" to prevent
    don> zone walking.  I put two options to the list in earlier
    don> posts; (a) one where the links between names are broken just
    don> a little, the other (b) where the NSEC links are completely
    don> broken.

If you don't mind online signing, you could synthesize a zone in which
every possible name exists and has, say, a TXT record saying
"non-existent domain".

This might make you unpopular with people who use domain-existence
checks as an anti-spam measure, though...

       -roy

---

From: Paul Vixie <[email-masked]>
Date: Sat, 29 May 2004 15:09:35 +0000

> No, it isn't.  But it still leaves us with a problem.  

yes, and let's give that problem a name.  "dnssec-bis's design does not
include certain confidentiality features which a number of domainholders
appear to want or need."  in other words let's call this a design change
rather than a quality problem with either the current docset or current
protocol.  this distinction matters to our WG chairs for administrative
reasons, whereas the design change will only matter to IESG.  we may in
fact have hit the target we were aiming at, but some say it was the wrong
target.

> DNSSEC.

yes, it will.  dnssec can still be deployed in a lot of places, including
the root zone and many TLDs including SE and NL.  there are four different
"islands of trust" models floating around in various research camps that
could cause a lot of dnssec deployment to occur even excluding NZ, UK, DE,
and probably COM and NET who all object to the enumerability of subdomain
names under dnssec-bis.

> or at least NSEC, need to be "broken" to prevent zone walking.  ...

i consider option (2) to be quite viable.  i've also spoken (on the "new
TCR" thread i began 12 hours ago) of the dangers of trying to change the
dnssec-bis design at this late date.  those of us who are itching to begin
deployment during 2004, which is the tenth year since dnssec was first
spoken of, are shaking with fear of any form of option (3).

> anyway", as I'm sure the folks peddling PKI & CA services would just

i think you should read the "new TCR" thread, and i think that all of the
domainholders who can't tolerate enumeration should contact jim reid to
talk about joining dns-moda and making DNSSEC-ter a first year priority.

and that you should study auto-msj, auto-johani, dlv, and any possible
other island-of-trust brokerage mechanism that could be used for early
deployment by your subdomainholders.

---

From: Roy Badami <[email-masked]>
Date: Sun, 30 May 2004 00:13:59 +0100

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:
    Paul> yes, and let's give that problem a name.  "dnssec-bis's
    Paul> design does not include certain confidentiality features
    Paul> which a number of domainholders appear to want or need."  in
    Paul> other words let's call this a design change rather than a
    Paul> quality problem with either the current docset or current
    Paul> protocol.  this distinction matters to our WG chairs for
    Paul> administrative reasons, whereas the design change will only
    Paul> matter to IESG.  we may in fact have hit the target we were
    Paul> aiming at, but some say it was the wrong target.

Was there ever a well-specified target?  Though I tend to agree that
the specs have met the target that the WG felt it was working towards
(not that I've followed the WG closely).

    Paul> i consider option (2) to be quite viable.  i've also spoken
    Paul> (on the "new TCR" thread i began 12 hours ago) of the
    Paul> dangers of trying to change the dnssec-bis design at this
    Paul> late date.  those of us who are itching to begin deployment
    Paul> during 2004, which is the tenth year since dnssec was first
    Paul> spoken of, are shaking with fear of any form of option (3).

I'm one of the many people you mentioned in passing in a previous
thread who had been waiting until the docs are declared 'finished'
before paying close attention to them.  I share your fear of option
(3) even if that might not be obvious from some of my recent posts.

Although my ideal scenario would be for Nominet and the IETF to reach
a consensus, new specs (if necesary) be drafted, and DNSSEC be
depolyed both in the root and in .uk all within 2004, this clearly
isn't goint to happen... 

Islands of trust would seem to be inevitable during the early stages
of deployment, and I thank you for the references on this subject...

    -roy

---

From: [email-masked]
Date: Sat, 29 May 2004 23:06:22 +1200

-- don

---

From: Alex Bligh <[email-masked]>
Date: Sun, 30 May 2004 12:49:32 +0100

> for all non-existent domains, but will reliably prevent zone walking.

Two questions:

1. Is there a situation where lack of authenticated denial can result
   in returning the wrong data in response to a query (meaning as opposed
   to returning no data when there isn't one)? - i.e. if NSEC were optional,
   does one leave oneself open to more than a denial of service attack
   where non-existence is spoofed? (I am asking here to what extent
   whether temporarily dropping authenticated denial in those zone operators
   with problems with enumerability is likely to be a fair price to pay).

2. Do people agree that, if lack of authenticated denial is itself an
   insuperable problem in zones for which NSEC enumerability is problematic,
   then, **IF** one is going to fix the problem at all, one might as well
   fix the enumerability problem in the general case (via NSEC2 or
   elsewise) rather than (say) provide an alternative mechanism of
   authenticated denial just for those not wishing to deploy NSEC, as
   the latter would involve just as much interoperability testing,
   development, specification etc. as the former. (I am asking here
   whether, if the problem is going to be addressed at all, whether
   NSEC2 or some similar NSEC replacement approach is in fact the best
   approach).

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sun, 30 May 2004 12:51:24 +0100

> checks as an anti-spam measure, though...

I seem to remember a recent experience where a wildcard was put
in one such zone did not meet with universal approbation.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sun, 30 May 2004 12:54:58 +0100

--On 30 May 2004 00:13 +0100 Roy Badami <[email-masked]> wrote:

> a consensus, new specs (if necessary) be drafted, and DNSSEC be

If you replace the word deployed with deployable (*) I think that is
a realistic target. As Jay indicated, we are happy to provide concrete
assistance in getting there.

(*) = production software ready to go.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 17:16:19 +0000

> (*) = production software ready to go.

it's now the end of june.  unless the change to dnssec-bis were as simple as
"add an MBZ octet to DS, DNSKEY, RRSIG, and require current implementations
to ignore RRs where this octet has a nonzero value" then we're not going to
see "production software ready to go" again in 2004.  patches are fine, but
maturity has been a challenging issue for dnssec.  in NSD 2.0 and BIND 9.3.0
we have production dnssec-bis software ready to go.  change dnssec-bis more
than the tiny amount described above, and we're into 2005 before we have
enough maturity to again call it production ready, no matter what patches
are developed or how good those patches are.

i don't think the average person on namedroppers@ realizes how much pizza and
late nights and whiteboards and "operability testing" went into stabilizing
dnssec-bis and getting confidence that it would work.  that's how "the
grandparent problem" was found.  that's how "TCR" was first proposed (and how
"the middlebox problem" was found, which drove "TCR").

patch-and-publish is fine when the torchbearing mob is at the castle walls
demanding a workaround for sitefinder.  it's not fine when reworking dnssec.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 17:30:44 +0000

I mean of course..

> it's now the end of june.

...that it's now the end of may.

---

From: Don Stokes <[email-masked]>
Date: Mon, 31 May 2004 11:32:52 +1200

>and probably COM and NET who all object to the enumerability of subdomain

From where I sit, the signing of the root zone is the real key to what
we do.  As far as the Internet at large is concerned, without the root
and the majority of registries signing their zones, DNSSEC is just a
toy.

So the real question in my mind is, will DNSSECbis be deployed on the
root?  Or will it have to wait for DNSSECter.

If the root zone is going to be signed using DNSSECbis, then NZ
will want to be doing *something* with DNSSECbis.  Which means some form
of option (3).

I know it gives you the shivers, but providing authenticated chains of
trust for DNSSEC-enabled domains that do exist seems to me a heck of a
lot more productive than futzing around with IoT brokerage schemes. 
Especially if we can do some type of option 3a rather than 3b and retain
authenticated denial. 

>deployment by your subdomainholders.

Islands of trust is not DNSSEC deployment as far as a TLD is concerned.
Sub-domain holders can do what they like; that's why we call it delegation.

In terms of specifications, I agree that trying to change DNSSECbis at
this stage is probably pointless.  We might as well get -bis out now, so
that enterprise deployment can occur -- for the most part, enterprises
don't have the same privacy concerns as registries for their internal
networks and DNS, yet could still benefit from DNSSEC. 

Meanwhile, lets get on with DNSSECter for deployment on the public
Internet.

-- don

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 May 2004 02:18:56 +0000

> root?  Or will it have to wait for DNSSECter.

the root zone is ftp'able, axfr'able, and otherwise not considered a matter
of confidential record.  therefore i don't think enumerability will be an
obstacle to signing the root.  all of the rootops can now support dnssec-bis.
therefore, it's down to the political problems like "who will know the signing
key" and none of those depend on the presumed delta between -bis and -ter.

> will want to be doing *something* with DNSSECbis.  Which means some form

if you're willing to tolerate another type code roll ("TCR++" for short) then
option 3 is on the table.  if you think, for some reason, that some other
form of extensibilty is necessary, then "option (3)" means "dnssec after 2004"
which would seem like a really painful last minute course change after all
the compromises and hard work that have gone into the "dnssec in 2004" effort.

> > ... you should study auto-msj, auto-johani, dlv, and any possible
> > other island-of-trust brokerage mechanism that could be used for
> > early deployment by your subdomainholders.
> 

i think you need to study it more closely.  your conclusions don't match the
facts as i know them.  i'm always willing to take this up 1x1, even by phone,
if that seems palatable.

> networks and DNS, yet could still benefit from DNSSEC. 

as the prime mover between one of the early deployment aids ("dlv") that
creates islands of trust, i can tell you that my scope is far beyond my own
local "enterprise".  i think that msj and johani would say the same.  so,
please study these alternatives more closely before you conclude about them.

> Meanwhile, lets get on with DNSSECter for deployment on the public

agreed.  and hopefully, because you said that, you'll be hearing from
jim reid about dns-moda.