Subject: Q19: supression of duplicate RRs in an RRset

From: "Scott Rose" <[email-masked]>
Date: Tue, 4 Nov 2003 14:37:11 -0500

This is (probably) another non-issue, but for procedural completeness:

Q19:  Should multiple instances of identical RRs in an RRset be reduced to a
single RR during the signing process?

Consider the zone file:

a.example.com    IN    A    1.2.3.4
a.example.com    IN    A    4.3.2.1
b.example.com    IN    A    1.2.3.5
...
a.example.com    IN    A    1.2.3.4

Going through the signing process.  Would the signer be justified in
dropping the second "a.example.com" RR from the "a.example.com A" and
leaving it as 2 RRs in the set?  That would effect the signature generation
process - it would be different if there was the third RR in the set.

Note that this is for the signature generation process and not loading or
serving the zone.  RFC 2181 cover duplicate RRs in a set for an operational
DNS zone (see Section 5).  The suggested text would be in line with RFC 2181
but for the signing process.

Suggested text is to add text to Section 6.3 (Canonical Ordering in an
RRset) of the Resource Records DNSSECbis draft stating that a duplicate RR
should be dropped from an RRset when generating a signature for the set.

Comments/questions welcome,  Silence will be taken in favor of adding the
check and performing the action during the signing process.

DNSSECbis editors

--
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: Wed, 5 Nov 2003 09:13:58 +0100

On Wed, 05 Nov 2003 01:35:19 +0000
Paul Vixie <[email-masked]> wrote:

> > > 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.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Olaf M.Kolkman <[email-masked]>
Date: Mon, 10 Nov 2003 08:46:56 -0600

>
> created.  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?

---

From: Roy Arends <[email-masked]>
Date: Mon, 10 Nov 2003 20:03:25 +0100 (CET)

On Mon, 10 Nov 2003, Paul Vixie wrote:

> > > .. if there are rdata duplicates then both the signer and validator
> > > should signal an error.
> >
> 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.

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

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

Roy

---

From: Roy Arends <[email-masked]>
Date: Tue, 11 Nov 2003 07:37:48 +0100 (CET)

On Mon, 10 Nov 2003, Paul Vixie wrote:

> 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.

The MIM properties are not that interesting. One attack would be to
influence the load balancing envisioned by the zone admin. I think we
agree that load balancing using dupes are atrocious to begin with. So
whoever wants to do loadbalancing is susceptible of this attack, which is
minor to begin with.

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.

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

No contest.

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.

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

Roy

---

From: Roy Arends <[email-masked]>
Date: Tue, 11 Nov 2003 18:39:41 +0100 (CET)

On Tue, 11 Nov 2003, Paul Vixie wrote:

> 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.

I agree, a description of behaviour, including reiterating 2181 on
surpressing duplicates would be good. No _new_ specification though on
hard requirements for the signer/validator to drop signatures on RRsets
containing duplicates, that would be too conservative for my taste.

Roy