Subject: Re: DNSSEXT Yokohama Minutes

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Sep 2002 17:46:35 +0000

can someone explain why we don't just outlaw wildcard records in signed zones?

--
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: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 04 Sep 2002 14:48:05 -0400

>can someone explain why we don't just outlaw wildcard records in signed zones?

Once you convince the world that following is not needed in any zone.

*       MX      10 <mail1>
         MX      20 <mail2>

Then killing wildcards is becomes a possibility.

         Olafur

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Sep 2002 13:14:27 -0700

> can someone explain why we don't just outlaw wildcard records in signed

folk use wildcard MX.  expect significant wildcard use in e164.arpa to
point whole city or country codes off to ldap servers.  etc.

randy

---

From: Roy Arends <[email-masked]>
Date: Thu, 12 Sep 2002 17:57:57 +0200 (CEST)

On Wed, 4 Sep 2002, Brian Wellington wrote:

> On Wed, 4 Sep 2002, Roy Arends wrote:
>
> > On Tue, 3 Sep 2002, Brian Wellington wrote:
> >
> > > On Wed, 4 Sep 2002, Roy Arends wrote:
> > >
> > > > > And then there is the issue on memory usage in caches, there was an
> > > > > assertation that opt-in zones cause more memory consumption than other
> > > > > DNSSEC zones.
> > > >
> > > > This is true,
> > > >
> > > > A positive response with Opt-in holds:    QTYPE+NXT+SIG(NXT).
> > > >
> > > > A positive response without Opt-in holds: QTYPE+SIG(QTYPE).
> > >
> > > The positive response with opt-in also needs to contain proof that there's
> > > no secure wildcard, otherwise secure wildcards can be spoofed away.  This
> > > will mean another SIG and SIG(NXT) in almost every case.
> >
> > No, you don't need proof for wildcards.
> >
> > If I was to spoof a resolver, proof of [non-]existence of secure wildcards
> > does not prevent or help me do that.
> >
> > If you asked for something in an unsecured interval, all bets are off.
> >
> > Remember that this is for delegations only. Are you suggesting proof
> > of [absent] signed wildcard delegations ?
>
> No, I'm suggesting proof of absent wildcards.  While opt-in might be
> restricted to delegations, that doesn't mean that the zone is.
>
> For example, consider the foo.com zone, with:
> @	SOA
> 	NS
> *	A
> a	NS
> c	NS
> e	NS
>
> Without DNSSEC, querying for www.b.foo.com will hit the wildcard A record,
> and querying for www.c.foo.com will return a referral.
>
> Now sign the zone, and have 'a' and 'e' signed, and 'c' unsigned:
>
> @	SOA
> 	SIG SOA
> 	NS
> 	SIG NS
> 	KEY
> 	SIG KEY
> 	NXT
> 	SIG NXT
> *	A
> 	SIG A
> 	NXT
> 	SIG NXT
> a	NS
> 	DS
> 	SIG DS
> 	NXT
> 	SIG NXT
> c	NS
> e	NS
> 	DS
> 	SIG DS
> 	NXT
> 	SIG NXT
>
> (Hope I didn't miss anything there)
>
> Query for www.c.foo.com.  According to your claim, you should just give
> out the referral (NS + DS + SIG DS) and the proof that the name is
> insecure (a's NXT and SIG NXT).

Almost, you should just give out the referral (NS) and the proof that the
name is insecure (a's NXT and SIG NXT).

> Query for www.b.foo.com, and have a malicious server replay a response
> with the same insecurity proof, and a forged unsigned referral.  There's
> no way to prove it's false, and you've now spoofed away the existence of a
> secure name, since www.b.foo.com was secure in the non-optin case.
>
> Yes, this is bad.

The problem is that when a query falls in an unsigned interval (yes, I
know, delegations only) there may exist an unsigned delegation for QNAME
eventhough there exist a signed wildcard.

Whenever a query hits an unsigned interval, it is useless to proof of
existing or non-existing wildcards.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Sep 2002 21:10:38 +0000

> This isn't a problem of not handling NXT records correctly.  The problem
> is that with DS, referrals to unsigned delegations contain NXT records. A
> response with an empty answer section and NXT records in the authority
> section looks a lot more like a negative response than a referral to a 
> server that doesn't speak DS.

i know it "looks a lot more like" and is a problem for at least one server
we know about (BIND 9.2.1).  however, before we call this a showstopper and
choose a different encoding for this condition, can we survey the other,
more popular server implementations and see if there aren't any?

---

From: Jim Reid <[email-masked]>
Date: Wed, 18 Sep 2002 02:22:25 -0700

>>>>> "Brian" == Brian Wellington <[email-masked]> writes:

    Brian> It's important for you, not for them.  Do you really think
    Brian> the users care how long it takes to sign .com?

Of course not. Though they will care if the signing time has an impact
on how quickly new delegations get published.