Subject: Re: NSEC+ and NO

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

Paul Vixie <[email-masked]> wrote:
>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.

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

--
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: 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).

> ...

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: 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: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: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: Don Stokes <[email-masked]>
Date: Mon, 31 May 2004 11:32:52 +1200

>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