Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response.

From: Samuel Weiler <[email-masked]>
Date: Mon, 28 Jul 2003 10:23:12 -0700 (PDT)

[Here's another message that kept bouncing.]

(Possibly reopening Q-9.  Sorrry, Scott.)

> More importantly, separating SIGs from what they sign is something to
> avoid.  Whenever you separate a SIG, you run into the possibility that
> the SIG you subsequently fetch will be for another version of the
> data.  When the SIG doesn't verify, the validator must not treat that
> as a failure of validation, but instead must refetch both data and its
> SIG and try again.

Given that the validator action when presented with an NXT and no SIG(NXT)
will probably be to query for that NXT, not SIG, is this worry mitigated?  
The (possibly new) data and accompanying SIG will arrive atomically, and
the new NXT will replace any stale NXT.

-- Sam

--
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: Rob Austein <[email-masked]>
Date: Mon, 28 Jul 2003 13:50:25 -0400

> the new NXT will replace any stale NXT.

This eliminates the version skew problem between the NXT and the
SIG(NXT), but now you you have the version skew problem between the
original RCODE and the requeried NXT/SIG(NXT).

The fundamental issue here is that SIG and NXT are part of what one
might call an "answer blob" (the collection of conceptually related
stuff that one gets back in response to a particular <qname, qtype,
qclass> query at a particular time), and requerying for just part of
an answer blob always opens up the possibility of a version skew.

---

From: Bob Halley <[email-masked]>
Date: 28 Jul 2003 15:03:33 -0700

> an answer blob always opens up the possibility of a version skew.

Also, every time you add more cases that you expect the validator to
deal with, the more likely it is that implementors will forget a case,
produce an incorrect validation, crash the server, etc.

It also makes it harder for people to validate the validator by
auditing the code.

For all these reasons, I think we should be trying to make things as
simple as possible for the validator.

/Bob