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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Apr 2003 05:41:49 -0700

Dan,

	What value do you claim there is to securing the delegation without
any security on the delegated zone?

	There has been a lot of security analysis on this issue, the only
security issue that has been raised is that of preventing an insertion
attack, a risk that is not relevant to a domain where anyone can buy a
domain.

	All anyone is talking about is adding crypto to the DNS, that is not
by any step of the imagination eliminating all risks, regardless of whether
you deploy with or without OPTIN. 

	Security is risk control, not risk elimination. Systems that attempt
to eliminate all risks, even those not relevant to a particular deployment
tend not to be deployed. We have had ten years of non-deployment here. Do
you really want to wait another ten?

	Without OPTIN DNSSEC becomes even more expensive to deploy than
PKIX. That is quite some feat.

			Phill

> -----Original Message-----
> From: D. J. Bernstein [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 2:44 AM
> To: [email-masked]
> Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN
> 
> 
> Hallam-Baker, Phillip writes:
> > the security considerations of an unsecured delegation and a secured
> > delegation to an unsecured zone are exactly the same
> 
> The same argument cuts both ways. To fix the existing 
> security disaster,
> we have to secure all the zones _and_ we have to secure the 
> delegations.
> If the .com people were prepared for this, they wouldn't need opt-in.
> 
> Opt-in allows the .com people to claim full DNSSEC support when the
> reality is that they can't handle a DNSSEC universe. It takes a failed
> security system and tries to pretend that it's a working system.
> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --
> 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/>
> 

--
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: Sam Weiler <[email-masked]>
Date: Wed, 30 Apr 2003 10:15:17 -0400 (EDT)

> attack, a risk that is not relevant to a domain where anyone can buy a

There's also the deletion ("spoof a zone out of existence") attack.
You can still replace the NS and make the zone unreachable, but you
could have done that just by stomping on the whole answer; DNSSEC
doesn't guarantee that packets get through.  Without opt-in, assuming
you get an answer at all, you at least get a verifiable statement of
existence -- you know that such a delegation exists and that something
is preventing you from reaching it.  That could trigger an IDS's alarm
bells, or it could tell you that you need to try harder to get the
answer.

Assuming that methods for "trying harder" are developed, you probably
don't want clients trying them all the time -- they'll probably be
bandwidth intensive or they'll try to get around caches and end up
pounding authoritative servers into the ground.  As an operator of
authoritative servers, your employer may be interested in minimizing
those events.  One way of doing that is to provide a very clear
trigger for when it's required.  You don't want all NXDOMAINS to turn
into a "flail on the auth servers" fest.

-- Sam

---

From: Roy Arends <[email-masked]>
Date: Wed, 30 Apr 2003 16:56:47 +0200 (CEST)

> There's also the deletion ("spoof a zone out of existence") attack.

Sam, when you use Opt-In, the domain that is 'skipped' using NXT is not
secured.  Its part of the definition, similarly: an unlocked door can be
opened. Don't blame the lock. Blame the policy for the door.

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

---

From: Daniel Massey <[email-masked]>
Date: Wed, 30 Apr 2003 11:19:40 -0400

> bells, or it could tell you that you need to try harder to get the

This has always seemed like nothing more than smoke and mirrors to me.

If I want to delete a zone  without opt-in,  I will send the valid NXT 
RR proving that the zone is not signed and I will make up any NS 
records of my choosing.   As Roy points out, security has ended at this 
point so all bets are off.  I don't see how the signed NXT RR has 
bought you anything here.

If I want to delete a zone with opt-in, I will send the valid NXT RR 
proving the range containing that zone is not signed  (and will 
optionally make up any NS records of my choosing or just say no zone).

I think you start to point out the tip of the iceberg:  if I can 
convince some IDS to do a look of work trying to check unsecure zones 
that can (by definition) never be authenticated,  then I believe I will 
have lots of fun making your IDS do a variety of bad things.   Good 
luck to your IDS design :)

Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Apr 2003 17:47:40 -0000

Hallam-Baker, Phillip writes:
> All anyone is talking about is adding crypto to the DNS

Security is not some optional feature that we want a few people to ``opt
in'' to. We need a security system that works for _all_ DNS records.

Evidently the .com people don't think they can sign all their records.
That's a serious problem. It has to be fixed. Opt-in doesn't fix it.

> any security on the delegated zone?

Communication from the zone server is often secured by mechanisms other
than DNSSEC. But this is a side issue.

I'm talking about a different situation, the situation we're aiming for:
namely, having _all_ zones signed. The .com people can't handle this.
Opt-in doesn't help the .com people handle it. Opt-in tends to hide the
fact that they can't handle it.

---

From: Sam Weiler <[email-masked]>
Date: Wed, 30 Apr 2003 14:24:40 -0400 (EDT)

> A secured delegation to an unsecured zone is as practical as an unsecured

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

So while the parent isn't authoritative for the NSset, it is making an
authoritative statement by the inclusion of a NXT.  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.

-- Sam

---

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

On Wed, 30 Apr 2003, Sam Weiler wrote:

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

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

> 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

---

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:

> 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
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