Subject: RE: Opt-in wg last call

From: "Peter Ford" <[email-masked]>
Date: Tue, 9 Apr 2002 16:15:48 -0700

In place of "fully secure zone" and "partially secure zone" how about:
"secure full zone" and "secure partial zone". (or perhaps "secure
optional zone")

The phrase "partially secure" just does not sound quite right.

Regards, peterf

--
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 Ford" <[email-masked]>
Date: Tue, 9 Apr 2002 16:15:48 -0700

Regards, peterf

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 15 Apr 2002 14:16:30 -0400 (EDT)

On Mon, 15 Apr 2002, Daniel Massey wrote:

> > I think this can be addressed by requiring that c.example must exist
> > and be secured otherwise it is to hard for the resolver to find
> > the correct NXT record that proves that f.e.d.c.example.
> > is the next secured name.
> >
>
> I'm not sure this fixes it....  would you allow the following:
>
>     b.example.  NXT c.example.
>     c.example.  A, SIG(A), NXT f.e.d.c.example, SIG(NXT)
>     d.c.example.  TXT ...
> f.e.d.c.example  A, SIG(A), NXT ..., SIG(NXT)
>
> In this case, won't you have a still have a problem with an
> attacker inventing a delegation for d.c.example (or other labels
> on the way)?

This NXT says there is no secure name between c.example and
f.e.d.c.example.
AND example has signing authority over f.e.d.c.example.

This implies there is no delegation.

>
> If I understand the fix, you change the opt-in NXT from:
>    b.example. NXT f.e.d.c.example
> to
>    c.example. NXT f.e.d.c.example

The resolver now checks the NXT for example, c.example, and is done.

In the other case the resolver had to try to find b.example or what ever
the name before c was. Thinking about this further I'm not sure
my original fix is enough, does every label needs to be secured ie
c.example.       NXT d.c.example.
d.c.example.     NXT e.d.c.example.  NXT
e.d.c.example    NXT f.e.d.c.example. NXT

Notice the NXT records with only NXT bit set, these indicate that
there is no record and no delegation at this name. (YUCK).

>
> I'm not seeing how the complexity of the resolver gets
> improved...
>

I'm not at this point interested in decreasing the
complexity of the resolver, only that it can answer the
question correctly.

	Olafur

---

From: Daniel Massey <[email-masked]>
Date: Mon, 15 Apr 2002 14:57:35 -0400

> This implies there is no delegation.

The "c.example NXT something.example" record proves there is no 
NS record and hence no delegation for c.example.  This prevents 
the attacker from making up a false delegation for c, but doesn't 
help prevent the attacker from making up delegations to 
d.c.example or e.d.c.example.

> e.d.c.example    NXT f.e.d.c.example. NXT

Yes, this is a better of way of saying what I was trying to express 
in the earlier message. I think adding the requirement that c.example 
be signed isn't enough....
  
But perhaps the lack of a delegation is implied by the next 
signed name.  Suppose you have:

  anything.example NXT f.e.d.c.example.

Is it correct to say this proves there is no delegation 
to c.example, d.c.example, and e.d.c.example?

Reasoning:  if there was a delegation to any of the
above, then the signed f.e.d.c.example record should
not be in the example.com zone and should not be pointed
to be the NXT in example.com.   

I'm not sure this is right, but if it is right then you
should be able to construct resolver rules that work.
The drawback is make the resolver code looks more complex...

Dan

---

From: [email-masked]
Date: Wed, 03 Apr 2002 09:38:30 +1000

> I agree.  Although I'm still not convinced that opt-in is the right 
> solution, I far prefer full opt-in to delegation-only restricted opt-in.
> 
> Brian

	Seconded.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 3 Apr 2002 11:25:49 +0200

> The only arguments in favor of limited opt-in I have seen have been on
> some kind of moral ground. Are there any technical arguments that I
> cannot see in favor of limiting opt-in?

I'm afraid I have been one of the persons voicing "moral"
objections. I will not repeat them here. But I still would like to see
the strongest possible recommendation not to use opt-in and sign zones
completely.

> When administrating DNS you are focused on the zone as a unit. DNSsec
> has also focused on that unit. But queries are not based on zone, and
> they can happily skip zones when parent and child resides on the same
> server, or some server happens to do resolving. Queries are based on
> names and its data, and opt-in refocus on names as being secured or not.

Detail: It has been mentioned that we loose the concept of secured
zones for the resolvers , I do not think that is true. Although the user's
application is only interested in a name with associated data the
resolvers will need to maintain state as to a zone is secured or not. If
the SOA is signed then names in that zone are either signed or opted-out. 

> I think I'll survive any decision taken in this matter. :-) 

That goes for me too. We should move forward. I would like to have
DNSSEC in production by the end of the year :-).

--Olaf