Subject: Re: Q19: supression of duplicate RRs in an RRset

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2003 13:23:28 +0000

> ... It is okay to have dupes on the wire or in presentation format.

i don't agree.

> > Since a 2181 compliant server should [1] suppress duplicates, it would
> > be foolish to assume than duplicates will reliably reach a validator.
> 
> Not at all. There might be implementations written by folk who interpret
> "should" less stringent as others.

2181 explains exactly what it means by "should".

> Lets not put any restrictions on the wire and presentation format.

we have to.  otherwise the rrset which is being signed and validated is
materially different from the one the zone administrator thinks that she
created.  if there are rdata duplicates then both the signer and validator
should signal an error.

--
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: Mon, 10 Nov 2003 19:20:12 +0000

> Paul, before the forwarder validates, it would surpress duplicates inside
> RRsets. The same is done before the signer signs the RRsets.

this means that what's being signed and validated is different from what
the zone administrator believes.  consider that someone who mistakenly
uses duplicate rdata to indicate load balancing preferences will end up
not changing the signature of the resulting rrset, even if the difference
is the removal of a duplicate, or the addition of duplicates beyond just
one.  this yields interesting MIM possibilities since a forwarder could
remove OR ADD duplicates, perhaps lots of duplicates, without making the
rrset's signature invalid.

> Duplicates on wire can't be outlawed by the DNSSEC rewrite.

you're right, but only because 2181 already did so.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Nov 2003 16:53:48 +0000

> The MIM properties are not that interesting. ...

I agree.  It was just an example.  The covert channel argument is another.

> If the plan would be to DoS one of the balanced server to begin with, and
> the possibility of MiM'ing is a requirement to deploy the attack. The
> actual DoS would be much simpler to implement by just flipping a random
> bit, causing a sig to fail.

This is off topic but I don't agree just the same.

> What we could probably agree on is that duplicates would/should not reach
> a signer/validator, since it would/should be dropped on inception by the
> server/resolver, due to 2181.

Yes.

> So there is no need to specify anything on duplicates, right ?

That will have the right effect, yes.  An overly liberal signer will still
generate signatures for rrsets containing duplicate rdatas, but those
signatures will be different depending on how many (including zero)
duplicates are encountered.  Therefore cooperating overly liberal endpoints
can sign and validate rrsets containing duplicate rdatas, and strict
2181 implementations can treat duplicate rdatas as format errors.

But it's possible that this should be spelled out explicitly in the docset,
since it's been observed to be a complex and difficult subject.