Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN

From: Roy Arends <[email-masked]>
Date: Wed, 30 Apr 2003 20:48:26 +0200 (CEST)

On Wed, 30 Apr 2003, Sam Weiler wrote:

> On Wed, 30 Apr 2003, Roy Arends wrote:
> >
> > Protection against your deletion ("spoof a zone out of existence") attack:
> > sign the delegated zone.
> >
> > A secured delegation to an unsecured zone is as practical as an unsecured
> > delegation.
>
> Roy,
>
> As Dan so ably points out, signing a child zone won't protect it from
> someone corrupting the NS glue, whether or not there's a DS in the
> parent.  But adding the NXT to the parent, with or without a DS,
> signals the existence of the delegation.

Sign the delegated zone implies the parent signs the delegation, i.e. add
the DS/NXT/SIG set. I didn't want to spell it out, I thought it was
obvious.

> A client seeing an NXT at least knows that the delegation exists.  It
> may not know how to find it, for inability to get the glue or because it
> was fed bad glue, but it knows that it's there.  That's a different and
> more informative failure mode, and there may be ways of recovering from
> it.
>
> In an opt-in zone (in an unsecure span), you're telling the client to
> fallback to the current state of the world: there's no reason to
> believe that there's anything in the span.

Sure, plain ol'dns.

> Without opt-in, you know something should be there, and you can try to
> recover (not that we know how, yet).

No, there is no recover. DNSSEC is simply error detection, not error
correction. You can detect an error merely by validating a sig. No sig,
no validation. If a certain branch does not want to be secured, why bother
do this in some intersection. Either you sign the whole intersection
(delegation at parent (NXT/DS/SIG) AND the delegated zone) or you sign
neither, any other combination is not secure.

> And whether or not the child is signed makes no difference.
>
> Yes, this would be much more interesting if the parent signed the
> glue.  Too bad we're not redoing delegations at this point in the
> process.
>
> Yesterday, you wrote:
> > All authoritative records are signed, with or without opt-in, and
> > can be verified to be valid or not.
>
> Correct, but misleading.  The parent is authoritative for the
> existence of a delegation, and the existence is proved with an NXT and
> SIG(NXT).

I said "authoritative records" not "authoritative responses". There is
nothing misleading about that.

> So while the parent isn't authoritative for the NSset, it is making an
> authoritative statement by the inclusion of a NXT.

An Opt-In NXT record is interpreted as:
"authoritative that there are no signed delegations"

It is all in the eye of the resolver, if it queries for some endpoint, it
does not matter which entity states the authoritative 'unsigned'. Not
existant is then similar as to not signed to a secure resolver.

> Without opt-in, it makes an authoritative statement by the omission of a
> NXT ("there's nothing to see here, move along").  With opt-in, omission
> of the NXT is ambiguous.

Whatever,

If I want security, an open door has at much value as a non existant door.

Roy

--
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: Daniel Massey <[email-masked]>
Date: Wed, 30 Apr 2003 16:56:45 -0400

On Wednesday, April 30, 2003, at 02:24  PM, Sam Weiler wrote:

> signals the existence of the delegation.  A client seeing an NXT at
> least knows that the delegation exists.  It may not know how to find
> it, for inability to get the glue or because it was fed bad glue, but
> it knows that it's there.

in other words, you know that the parent thinks a delegation exists and 
have a proof there is now way you can every be sure you have reached a 
real server for that delegation.  so what?

> That's a different and more informative
> failure mode, and there may be ways of recovering from it.
>
such as??

perhaps I'm not understanding your claim, but it reads to me as there 
may be some yet to be thought of way to use DNSSEC to help recover from 
errors reaching unsigned zones and we should not deploy opt-in because 
it may interfere with this yet to be thought  protection for unsigned 
zones.

I view DNS security adding value to signed zones.    if you want to 
avoid various problems, sign the zone.

using DNSSEC to try and recover from problems with unsigned zones is 
dangerous at best in my view.  a system that adds value to unsigned 
zones is a different problem from DNSSEC and I have not seen any 
justification or even promising approaches that applying to DNSSEC to 
unsigned zones would be helpful.   I would also say that trying to use 
the DNSSEC RRs to infer things about unsigned zones is something we 
should recommend strongly against (isn't one justification for changing 
the type codes based on the use of an NXT RR that can not be 
authenticated?)

Dan