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: David Blacka <[email-masked]>
Date: Tue, 4 Nov 2003 16:02:22 -0500

> single RR during the signing process?

Yes.  Signatures obviously don't work if what is signed isn't what is 
served.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Nov 2003 21:39:06 +0000

> single RR during the signing process?

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.

> a.example.com    IN    A    1.2.3.4

duplicate rdata is just too hard to think about.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 4 Nov 2003 18:50:01 -0500 (EST)

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

Absolutely.  See the discussion about ambiguous formats in the large
typecode thread.

-- Sam

---

From: Rob Austein <[email-masked]>
Date: Tue, 04 Nov 2003 20:11:46 -0500

> be able to transfer them, or query be able to return them.

But if for some reason a zone signer were somehow to see such
duplicates, said zone signer should generate signatures based on the
RRset with the duplicates removed.  Right?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Nov 2003 01:35:19 +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.
> 

ideally not.  a zone signer should signal an error and give up under
those conditions.  silently ignoring bad data is not always a favour,
especially where security, and zone identity, are concerned.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 5 Nov 2003 09:13:58 +0100

On Wed, 05 Nov 2003 01:35:19 +0000

> > > see them, nor should axfr be able to transfer them, or query be able

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: "Scott Rose" <[email-masked]>
Date: Wed, 5 Nov 2003 08:51:26 -0500

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 04, 2003 4:39 PM
Subject: Re: Q19: supression of duplicate RRs in an RRset

> arguably not.  these should be removed during the process of
reading/loading/
> be able to transfer them, or query be able to return them.

The signature generataion process could be seperate from the zone
loading/serving process.  A duplicate RR in a set may slip through the
signer, then be caught by a name server during reading.  By then, it is too
late, the RRSIG is incorrect and will not be verified by a resolver.

The idea that it should not be silently ignored is probably better.  That is
another option to state/replace in the drafts.

Scott

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Nov 2003 18:00:50 +0000

> But it is not only the signer that is able to get duplicates the validator 

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: Roy Arends <[email-masked]>
Date: Wed, 5 Nov 2003 09:44:12 +0100 (CET)

> be able to transfer them, or query be able to return them.

Lets do worst case, and go with robustness principle.

Disambiguate the RRset for cryptographic processing _only_.  The
disambiguation algorithm is documented, and has no bearing on whatever
format the RRset itself leaves or arrives on the wire.

Duplicate records in a RRset are legal and used for (imaginary) load
balancing purposes (yes, I don't like it either).

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 9 Nov 2003 20:19:43 -0500 (EST)

> format the RRset itself leaves or arrives on the wire.

You mean by suppressing duplicates, right?

> balancing purposes (yes, I don't like it either).

RFC2181 (proposed standard), Section 5: "It is meaningless for two
records to ever have label, class, type and data all equal - servers
should suppress such duplicates if encountered."

Since a 2181 compliant server should [1] suppress duplicates, it would
be foolish to assume than duplicates will reliably reach a validator.

If we want to change that and come up with a disambiguation scheme
that accomodates duplicates, then we need something other than
2181-compliant servers transporting the data.

In other words, we should give up now.

-- Sam

[1]  2181, section 3:
   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
   their negative forms.  In some sections it may seem that a
   specification is worded mildly, and hence some may infer that the
   specification is optional.  That is not correct.  Anywhere that this
   memo suggests that some action should be carried out, or must be
   carried out, or that some behaviour is acceptable, or not, that is to
   be considered as a fundamental aspect of this specification,
   regardless of the specific words used.  If some behaviour or action
   is truly optional, that will be clearly specified by the text.

---

From: Roy Arends <[email-masked]>
Date: Mon, 10 Nov 2003 05:18:43 +0100 (CET)

> You mean by suppressing duplicates, right?

Yep, for crypto purposes only. It is okay to have dupes on the wire or in
presentation format.

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

> In other words, we should give up now.

Sure. We agree. Disambigation text (canonical form for RRsets) needs to
include text on surpressing dupes.

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

Roy

---

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.

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

---

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.

---

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

---

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

> the same condition as "signature failed to validate" which means, i

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: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2003 19:20:12 +0000

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

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

> bit, causing a sig to fail.

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

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

---

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

> 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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 27 Nov 2003 10:15:19 +0100

Q19: Suppression of duplications

      This issue is about the canonicalization process by the signer and
      the verifier.

      Duplicates are specifically forbidden. On the list there have been
      several oposite opinions with regards to how to deal with this issue.

      We propose the following text as consensus position:

      Duplicate RR records are not allowed exist according to
      [RFC2181]. Implementations MUST therefore treat duplicate RR
      records as protocol errors. Signers and verifiers MUST
      canonicalize duplicate RR sets by removing duplicate RRs from
      the set if the implementation is designed to be liberal in
      handling protocol errors.

      If there is no further prohibitive objections by December 8 this 
      will be taken as consensus of the working group.

-- Olaf
   DNSEXT co-chair