Subject: Re: Denial Of Existence: Way Forward

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Oct 2004 11:28:43 +0100

Olaf,

--On 28 October 2004 09:32 +0200 "Olaf M. Kolkman" <[email-masked]> wrote:

> == Denial of Existence and zone enumeration and a way forward.

Thanks for your note, none of which I disagree with.

However, there is one other item that I *think* has now become entangled
with zone enumeration (and should probably stay entangled). This is support
of unsigned portions within a signed zone file (i.e. proposals giving
similar functionality to OPTIN). Having gone around the "why do people want
protection against zone enumeration" loop, it seems that there may well be
a large overlap in people who want that protection and those who want
support of unsigned portions of a zone file; and further, that if the
solution to zone enumeration is introducing a new NSEC variant, this could
be fixed at the same time. It is, after all, in the requirements document.

I therefore wonder whether, when considering your questions (1)-(3),
whether they should not be asked in the context of zone enumeration
protection and (perhaps) optional support for unsigned areas of zone.
This may produce more people willing to commit resource.

Alex

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 28 Oct 2004 13:51:42 +0200

This is a reply to "Re: Denial Of Existence: Way Forward" Note the
subject change though.

Alex Bligh <[email-masked]> wrote about introduction of "OPT-IN"
mechanisms.

> be fixed at the same time. It is, after all, in the requirements document.

Correct, but we also have a requirement for "Completeness", hence my
hint on the square (11,17) being green in my previous message.
However, after your post I reread section 17 and I think that "should
be possible" phrase in 17 does explain the green square.

I am still not enthusiastic about fully dropping the denial of
existence in a secured zone. And I think I should have worded
requirement 17 stronger:

  In a secured zone proof is available for the non-existence of all
  names that do not exist in the zone.

The main reason for this requirement is that as a "client" of DNSSEC I
do not want to be confronted with two security models. DNSSEC today
buys me the non-existence proof. As a client of the DNS I want all or
nothing. (I understand that all kind of client policy knobs can be
introduced but I do not think that is a good idea).

This is slightly different from having two ways (NSEC and NSEC++) to
deny existence of data. They do not alter the securtity properties for
the client (only for the zone owner; obsuration of content).

-- Olaf
   namedropper (hats off).

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Oct 2004 13:04:36 +0100

Olaf,

--On 28 October 2004 13:51 +0200 "Olaf M. Kolkman" <[email-masked]> wrote:

> existence in a secured zone.

I am not advocating dropping it - I am advocating making it optional
for parts of the zone (e.g. by having NSECx point the "next secure"
name and have an additional bit saying "between here and there there
may be zero or more insecure names").

> And I think I should have worded
> requirement 17 stronger:
>

You are back then to saying does 17 as reworded preclude the existence
of a partially secured zone?

> introduced but I do not think that is a good idea).

1. I am not suggesting it be compulsory :-) However, some people want
   incompletely signed zone-files because they are delegation only
   and 99% of the delegated zones are not secure - think of a TLD
   adopting DNSSEC - and they want to minimize the expansion in zone
   size and signing requirements.

2. I agree that it is not nice to have to cope with 2 security models.
   However, we already have that problem. If org.uk is signed
   (completely, i.e. without anything like opt-in), but alex.org.uk
   is unsigned, a client resolving www.alex.org.uk already has the
   problem of a return code that is "partially" secure - which it
   then has to treat as an insecure response - what the application
   does with it is up to the application. So I don't see any particular
   extension of the yuckiness if www.alex.org.uk returns an insecure
   result, www.abcd.org.uk returns a secure result, www.defg.org.uk
   returns a secure denial of existence, and www.hijk.org.uk returns
   an insecure denial of existence. IE as you've got to cope with
   unsigned names anyway, and insecure denial of existence anyway,
   I don't think there are additional client
   policy knobs to be introduced beyond what we've already got stuck
   with.

Alex

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 28 Oct 2004 16:17:55 +0200

> may be zero or more insecure names").

I think that we would agree on the security property of this: any name that
could exist between here and there cannot be securelly denied.

> of a partially secured zone?

Yes that is the effect of the rewording. The reworded text is was what
I had in mind when I submitted the requirement. Only now I realize
that it was not worded strong enough.

>    size and signing requirements.

I understand that argument. I also understand the pain of having to
generateand sign a huge number or NSEC[++] records. While we had this
discussion during the OPT-IN debate I suggested that I could live with
OPT-IN for delegating zones only.

After saying that I was taught that DNS protocol dependency on zone
content is bad design. And I have been convinced that that is indeed
the case.

>    policy knobs to be introduced beyond what we've already got stuck

I am not sure if I understand this argument. The security model is on
a per zone basis. In org.uk the situation is unambiguous and so is the
situation in alex.org.uk.

One could argue that there is little added value to DNSSEC in a
delegation-only zone as long as the children are not secure (Roy is
much better at arguing that than I am :-) ). But, the point is that
once we allow for an OPT-IN mechanism you could deploy that mechanism
on alex.org.uk and my resolver has to deal with the possibility that a
franction of your zone is not secured.

In other words, we have to assume that the solution that we design for
TLDs will be used throughout the DNS tree.

-- Olaf
   namedropper (no hats).

---

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Oct 2004 16:04:55 +0100

--On 28 October 2004 16:17 +0200 "Olaf M. Kolkman" <[email-masked]> wrote:

> I think that we would agree on the security property of this: any name
> that could exist between here and there cannot be securelly denied.

Yes. Though a name that does exist could have this fact securely
verified.

> situation in alex.org.uk.

OK let me rephrase - always possible I'm missing the point. Assume org.uk
is delegation only. Assume secure.org.uk is secure (i.e. DNSSEC-bis), and
insecure.org.uk is not. Further, assume www.secure.org.uk,
www.insecure.org.uk exist, and vvv.secure.org.uk, vvv.insecure.org.uk
don't exist.

At an API level (and I think this is what we are talking about), WITHOUT
INTRODUCING PARTIALLY SIGNED ZONES (i.e. assume org.uk is DNSSEC-bis
signed), you have the following results of a query (say) for an A
record:
  www.secure.org.uk - secure, exists
  vvv.secure.org.uk - authenticated denial
  www.insecure.org.uk - insecure exists
  vvv.insecure.org.uk - unauthenticated denial (*)

So the poor application / resolved library already has to adopt policy for
authenticated and unauthenticated existence and non-existence.

So, if partially signed zones were added, and a query was made for and
org.uk was instead signed that way, and notthere.org.uk falls into an
unsigned interval (see above) and does not exist, then a response for a
query of www.notthere.org.uk of "unauthenticated denial" is going to come
back. The policy logic for handling this I think already has to be there to
cope with vvv.insecure.org.uk.

I'm making an assumption here which is that at API/resolver library
level people only care whether or not something exists (and whether
or not that can be securely authenticated) - not why they don't
exist. IE www.notthere.org.uk is the "same" to an application as
vvv.insecure.org.uk, though the reason for the failure is different.

> TLDs will be used throughout the DNS tree.

Yes, though I don't see how that changes things.

Alex

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 28 Oct 2004 22:05:45 -0400 (EDT)

Olaf writes:

>   If possible people should argue their preference for requirements
>   that cannot be reconciled (e.g. the opt-in type 11 is preferred over
>   complete non-existence from 17). With any luck we can compose a list
>   of "reconcilable requirements".

I think there's a more productive direction to work from.  About a
month ago, I posted a message saying:

> Given the potential for conflicting requirements, I'd find it useful
> to see what sets of requirements go together.  We might find that
> there are multiple disjoint sets of users with confliciting
> requirements, but that we can design a solution that works for each
> set (or at least some of the sets).  Does your raw source material
> give you enough data to start constructing that matrix?

The current matrix tells us what we can achieve, but it doesn't tell
us what users (registries) want.  We have a list of all of the
requirements, but we don't have sets (i.e. user X has requirements 3,
10, 14, and 15).

In particular, today's opt-in discussion has me wondering whether
having a subset of a zone (the secured names) be ennumerable would
present a problem for most of the users driving this work.  If so, we
need a solution that doesn't let that ennumeration happen.  If enough
users are okay with having all secured names ennumerable, perhaps we
can just use the old opt-in (alone or in combination with another
solution, like on-line signing).

I'm hoping that by looking at the sets, we can say "solution X will
help users 1,2,3", "Y will help 4,5,6", "Z will help 2 and 5", and "we
have nothing to help user 7".  Then we can decide to do X and Y and
let user 7 suffer.

-- Sam

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 29 Oct 2004 10:10:46 +0200

Olaf,

> 1) Who will commit to producing specifications for a denial of existence
> method that does not allow for zone enumeration;
> [...]
> 2) Who will commit on writing an implementation
> [...]
> 3) Who will commit on reviewing the material

There are individuals more capable than me to achieve 1), thus I am 
personally committing to 3).

Best,
Marcos

---

From: Alex Bligh <[email-masked]>
Date: Fri, 29 Oct 2004 10:04:05 +0100

> present a problem for most of the users driving this work.

It would for us. Non-enumerability of all names (secured and unsecured)
is what we need. opt-in would be a "nice to have" (in terms of
reducing zone expansion) but if it's extremely difficult / divisive
etc. (I hear it is, don't understand why, but wasn't on namedroppers
at the time) it's not a must-have.

Alex

---

From: Jay Daley <[email-masked]>
Date: Fri, 29 Oct 2004 10:26:31 +0100

Olaf

>     We would like to see at least 3 people, which will be assigned an
>     editors function, to commit.
> 
>     We would like to see at least 1 individual or group committing to
>     develop (or fund development) of an implementation.

We can certainly commit to doing and/or funding these two.

>     We would like to see a set of people, different from the set of
>     editors, to commit to review throughout the development of the
>     specification.

As this is a function that is probably best separated from 1) and 2) above 
all I will say is that, if needed, we can support someone independent 
doing this.

We can also commit to doing and/or funding:

4)  Interoperability testing between different implementations.

Jay Daley
Nominet UK

---

From: Ben Laurie <[email-masked]>
Date: Fri, 29 Oct 2004 12:00:14 +0100

Olaf M. Kolkman wrote:
> == Way forward
> 
>   There are two (known) ways to approach denial of existence proofs.
> 
>     a. Dynamically generated NSEC RRs
>     b. Pre computed "NSEC++" RRs that use some hash scheme to 
>        obscure the namespace
> 
>   The requirements document that we have is implicitly based on 'b'
>   type solutions and can be used for further development.

I don't agree with this. The requirements are applicable to both 
scenarios, though clearly each one satisfies a different subset of the 
requirements. If it would be useful, I can document those subsets.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

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: Ben Laurie <[email-masked]>
Date: Fri, 29 Oct 2004 11:58:13 +0100

> This may produce more people willing to commit resource.

FWIW, this would be a natural outcome of the merging of the two NSEC++ 
documents (which I am partway through and would be happy to complete a 
first cut).

I see from later discussion that some are not in favour of this, which 
leaves me unsure how to proceed. If opt-in is dropped, then (from 
memory), the only remaining point is whether hashing is done per-label 
or over the whole name. The obvious issue with per-label hashing is that 
it makes the hashed name even longer, and length is already a problem.

Cheers,

Ben.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 29 Oct 2004 16:32:22 -0400 (EDT)

On Fri, 29 Oct 2004, Ben Laurie wrote:

> If opt-in is dropped, then (from memory), the only remaining point
> is whether hashing is done per-label or over the whole name.

In San Diego, I did presentation comparing the two NSEC++ proposals,
but I don't think a summary ever made it to the list (sorry about
that).  The slides are in the meeting proceedings:

http://www.ietf.org/proceedings/04aug/slides/dnsext-7.pdf

To summarize, in addition to the choice of whether hashing is
per-label or not [1], the two proposals had three "options": opt-in,
allowing hash iterations, and defining a null hash function.  I think
we can pick and choose among these, and I think both the iteration
option and the null hash option are pretty trivial, but I don't recall
us making any decisions about them.

In my presentation, I also faulted both proposals for not describing
how to change hash functions or salts (or number of iterations) and
for not going into enough detail about wildcard processing.  Both of
those need to be addressed.  I also worried about hash collisions,
though people keep trying to convince me that the probabilities of a
collision can be made vanishingly small.  I'd rather see a mechanism
for rolling (or allowing for coexistence of multiple) hashs and/or
salts, but I'm willing to drop the collision concern.

-- Sam

[1] The choice of whether to do per-label or whole-name hashing could
require the introduction of an EXIST RR and other changes to wildcard
processing rules.  Each choice also reveals different information
about the zone: whole-name hashing (NSEC2) exposes the names of empty
non-terminals (via the EXIST RR); per-label hashing (DNSNR/NSEC3)
exposes the structure of the zone but not the names.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 29 Oct 2004 16:43:23 -0400 (EDT)

On Fri, 29 Oct 2004, Ben Laurie wrote:
>
> The requirements are applicable to both scenarios, though clearly
> each one satisfies a different subset of the requirements. If it
> would be useful, I can document those subsets.

I think this will be useful -- it will help us compare the
requirements sets (see my message from yesterday) to the solutions.

Also, I apologize for not being clearer in my original request for
the requirements sets.

-- Sam