Re: DNSSEXT Yokohama Minutes

[Brian Wellington <Brian.Wellington@nominum.com>]

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

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.

Brian


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>