To:
Sam Weiler <weiler@tislabs.com>
cc:
dnssec@cafax.se
From:
Slawomir Gruca <slawekgr@nask.pl>
Date:
Fri, 16 May 2003 08:57:06 +0200 (MET DST)
In-Reply-To:
<Pine.GSO.4.33.0305151356230.5045-100000@raven>
Sender:
owner-dnssec@cafax.se
Subject:
Re: NXT issues
> > in a nutshell - would the NXT without the 'next canonical name'
> > field be sufficient for a resolver to get the message that there
> > is no domain?
>
> No. Assume that you redefined NXT to not have the name.
> com NXT bitmap
> a.com NXT bitmap
> d.com NXT bitmap
> And a client queries for c.com. You presumably return a.com NXT. What
> if the client asks for d.com? Why couldn't you return a.com NXT?
> More importantly, what keeps an attacker from replaying the a.com NXT
> in response to the query?
>
> If you remove the 'next name' field, the algorithm for seeing if the
> client got an appropriate ("covering") NXT changes: you're left simply
> checking whether the NXT is in-zone, if you even bother with that.
> That algorithm allows any name in the zone to be spoofed away. You
> might need some special handling for the zone apex, though, since you
> presumably need the keys from the apex to verify any other NXTs, so
> trying to spoof away 'com KEY' by sending a.com NXT would generate an
> interesting case.
>
> -- Sam
Firslty, Sam, thank you for the explanation.
I've asked all those questions just to make sure that my idea is missing
something:-) I thought replaceing 'next domain field' with its hash
value (e.g. its SHA-1 digest) wouldn't affect the security level of DNSSEC
and additionaly would protect a zone from being copied (I think
one of the major DNSSEC's drawbacks is that anyone can obtain the zone
data really fast using the NXTs). Unfortunately, such system would be
vulnerable to reply attacks, as Sam explained. Anyway, the internal
consistency of a zone would be provided :-)
Slawek