Subject: Re: Q-10: Reaction to "Silly" NXT's

From: [email-masked]
Date: Fri, 06 Jun 2003 07:07:57 +1000

> On Tue, 3 Jun 2003 22:12:31 -0700
> Edward Lewis <[email-masked]> wrote:
> 
> > First I'll assume the context of this is that the NXT is in the 
> > authority section and appears in one of the messages as described in 
> > RFC 2308, including the referral.
> 
> ACK.... If the NXT appears in the answer it is irrelevant to any
> proof. That is I think that is in the "spirit" of 5.3 of the protocol
> doc.  (It appears in the answer section because of a direct query for
> QTYPE=NXT or QTYPE=ANY).
> 
> 
> > The right way to do this step is to take the NXT and it's SIG and try 
> > to build a chain of trust back to a configured key.  
> (... skipped ...) 
> 
> I agree. The assumption below is that you can follow the chain of
> trust all the way to the key that made the signature.
> 
> 
> >
> > >
> > >2. Given that the zone is secure you only process NXT RRs to proof
> > >   non-existence of names or non-existence of RRtypes.
> > 
> > I disagree with this...as before.  If I can validate the NXT, the 
> > zone must be secured.  If I can't I need to either get the NXT 
> > (absent but expected) or I discard the NXT (present but unexpected).
> 
> Let me rephrase:
> 
> You will only get a NXT RR to proof the non-existence of a name or
> the non-existence of an RRtype with a name. We assume the validator has
> validated the  NXT RR i.e. it is present and expected, and the crypto
> workes out.
> 
> 
> > >3. If either a NXDOMAIN or NOERROR empty answer section is received one
> > >   first verifies the SIG over the NXT RR to check if that has not been
> > >   tampered with. If it has been tampered with mark the answer as
> > >   BAD. (Bad luck, either the zone served incorrect data or your answer
> > >   has been tampered with)
> > >
> > >   The SIG(NXT) is correct so we have to verify if the NXT RR is relevant
> > >   to the answer.
> > >
> > >   (If the answer is NOERROR and a non-empty answer section we have a
> > >    direct match and the NXT RR is IMHO irrelevant; all the proof
> > >    for the data in the answer section is enclosed in the answer)
> > 
> > This is the step where I realized that there's something missing from 
> > the discussion.  Once you have cryptographically determined that the 
> > NXT is valid (let's assume this is the processing path), then you 
> > need to understand the context to see if it is relevant.
> > 
> 
> Agreed.
> 
> > In a referral message, with a negative indication for the DS, you 
> > need to see that the NXT claims that there is no DS but there is a 
> > SIG and NXT for the name, as well as NS's.  If that's not the case, 
> > the NXT is inappropriate - or falls under the silly state proposal.
> >
> 
> 
> 
> More precise based on the current protcol docs:
> 
>  in a referral message:
> 
>  The owner name must be the same as the owner name of the delegation
>  RR besides the NXT bitmap needs to bits set to 1 for the NS, 0 for
>  the DS and 0 for the SOA. This is all what is relevant to the
>  validator for validating the answer
> 
>  A verifier does not _need_ to check any of the other bits. If it
>  chooses to check the bits the NXT and SIG are supposed to be set to 1
>  and all the other bits are supposed to be set to 0. Anything other is
>  silly state (not only SIG or NXT being set to 0 is silly state but
>  e.g. an AAAA bit set to 1 is also silly state)
> 
> 
>  in a NOERROR empty answer message:
> 
>  The owner name must be the same as the owner name of the returned NXT
>  record. The bit in the NXT RR corresponding to the QTYPE needs to be
>  set to 0. For this query all the other bits are irrelevant so again a
>  verifier does not need to check any of the other bits. If it chooses
>  to check other bits then the NXT and SIG bit are supposed to be set to
>  1, otherwise it is a silly state (there is another silly state, if
>  the NXT bitmap contains a SOA and an NS there is not supposed to be a
>  DS)
> 
> 
> 
> The point I was trying to make is essentially that one never uses the
> bitmap except for checking if a bit has actually been set to "0" (for
> a NOERROR empty answer reply) or if the SOA bit is set to "1" or "0"
> at a zone-cut.
> 
> The protocol does require a check to see if any of the other bits are
> actually set to 1; without your proposal the NXT and the SIG bit may
> be completely ignored.
> 
> In other words your proposal should include a "MUST verify the state
> of the bits not relevant to proving the answer" otherwise things will
> become very messy. Alternatively the protocol docs could say that
> "verifiers MUST only verify the bits that are relevant to the answer",
> that excludes sily states alltogether; you just do not care about the
> settings of the other bits.
> 
> 
> 
> Another worry, the ownername; Do I read correctly that a silly state
> does not allow for an owner name different than being expected(#) in
> other words are ownername checks performed before or after the silly
> state has been determined. (The argumentation above is based on the
> ownername being as expected.)
> 
> If in a silly state the owner name is allowed to be different from
> you should specify that the silly state first needs to be determined
> and that one then needs to do the ownernameckeck. (A detail is that if
> you allow for different owner names the silly state indicators reduce
> to NXT ans SIG only).
> 
> 
> --Olaf
> 
> 
> 
> (#) The NXT ownername that is expected is:
> 
> NXT ownername < QNAME if RCODE=NXDOMAIN
	+ NXT for non-existance of wildcard.
> NXT ownername == NS ownername in case of delegation
> NXT ownername == QNAME in case of NOANSWER
  NXT ownername < QNAME if wildcard answer.
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 6 Jun 2003 12:25:46 +0200

On Fri, 06 Jun 2003 07:07:57 +1000
[email-masked] wrote:

(Two minor additions to the expected NXT list at the bottom of the original 
 posting)

>  	+ NXT for non-existance of wildcard.

Ack.. both are NXT ownernames are < QNAME.

>    NXT ownername < QNAME if wildcard answer.

Ouch... 

But the ownername is still predictable.  

The one relevant to the proof for NOANSWER is has the wildcard as
ownername.  (You will also get a NXT RR that proofs there is no closer
match than the wildcard but the NXT bitmap of that RR is irrelevant to
the proof of non-existence of the QTYPE)

Question remains:

Are you first going to check the if bits are in a silly state so you
know you do not have to expect a NOANSWER proof with the expected
owner name (the NXT with the wildcard itself) or is the check simply:
Check if ownername is relevant and then check that the bit for QTYPE
is set to 0.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi