Subject: Re: Section 4 of dnssec-protocol-03

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Nov 2003 18:07:13 +0000

> > ... thing i heard from -editors was that it was all about clarifying
> > 2535.  apparently then, rolling up TCR et al will come later?
> 
> Forward (and backward) reference:
> 
>   From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
>   To: [email-masked]
>   Subject: DNSSEC editing process (Periodic posting)
>   Date: Fri, 31 Oct 2003 20:23:11 -0500
> 
>   "The DNSEXT working group has started a rewrite of the DNSSEC
>    specification into a documents that better reflect the protocol
>    and allow a test plan to be constructed from the specification.

in other words it should include TCR and anything else that's changed
the protocol in the post-2535 era?

>   (...)
>   If clarifications are needed due to conflicting definitions,
>   imprecise specification, omission or other reason, the editors MUST
>   bring these issues to the attention of the working group on the
>   namedroppers mailing list.
>   (...)
>   "

does passing WGLC meet the standard for "bring to the working group"?
if so, then dnssec-bis will have to be fully inclusive of all post-2535
work, and as far as i know, it is not as of this time.

> We need closure on the document set so let us not revisit issues that
> have been fixed through the submission and acceptance of drafts that
> where needed to clarify the specs.
> 
> On the other hand, do bring issues to the list. It is a sign of
> thourough review. If an issue has been covered we have the archives
> and/or the specs to point to.

i guess we've been asking the wrong question so let me start over.

is dnssec-bis supposed to be fully inclusive of all post-2535 work, such
that an implementor can just read that one doc set, or is it just a
clarification of 2535, and an implementor will have to read dnssec-bis
PLUS every post-2535 document?

the answer to this will radically influence the document review process.

--
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: Paul Vixie <[email-masked]>
Date: Wed, 05 Nov 2003 18:00:50 +0000

> > > > arguably not.  these should be removed during the process of
> > > > reading/loading/ importing the zone, and so the signer should never
> > > > see them, nor should axfr be able to transfer them, or query be able
> > > > to return them.
> 
> But it is not only the signer that is able to get duplicates the validator 
> may get them too.

since that would unambiguously be a protocol error rather than a MIM attack,
i think it would be correct to signal an error under those conditions, too.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2003 14:49:52 +0000

> > .. if there are rdata duplicates then both the signer and validator
> > should signal an error.
> 
> And still be liberal in what they expect, i.e. forward the answer with
> duplicates stripped and final answer verified to the application?

no.  a validating forwarder would turn an answer with dup rdata's into
the same condition as "signature failed to validate" which means, i
think, dropping it.