Subject: [dnsext] Name equivalence tricks - tools for building solutions

From: Brian Dickson <[email-masked]>
Date: Fri, 10 Sep 2010 00:39:32 -0300

I believe the main issue on name equivalence, is where DNSSEC meets name
equivalence.

We have several threads ongoing at this time, related to the problem
statement, the need for a problem statement, a variety of suggestions and
proposals.

I propose to create a thread dedicated to "a-ha" ideas that can help
generate solutions, or refine solutions, or make the problem more scalable.

I'll start with a not-terribly-obvious, but quite-helpful one.

--

Signature-Steganography

Observe the following - a signature must be validated, whether it be an
RRSIG or a DS, based first on the owner name and signer name, and then based
on combinations of algorithm and dnskey and matching key-id.

In order to validate a signed RRset, there needs to be a valid RRSIG (or in
the case of NS, a valid DS).

However, there is no fundamental reason that known-invalid RRSIG/DS records
cannot be included along with known-valid records.

And while there are limits to response sizes, there's no problem with a
reasonably large number of signatures, as long as there's a good reason for
having them.

This leads to the following idea:

The same data, with multiple signatures, where the input to the signature
(i.e. signer + owner) varies over a number of alternatives (i.e. suffixes).

Consider an RRset with owner "foo.bar_1", which has a set of RRSIGs
RRSIG_foo_i, where:
- "i" ranges over the number of aliases for a zone name bar_1
- there is a common fixed prefix is "foo"
- there is a variable suffix is "bar_i"
- "bar_i" is the name of the zone, and thus the signer for any RRSIG under
"bar_i", and the owner name for any DS for a DNSKEY at the apex of "bar_i"
- S_foo_i is based on the RDATA for foo.bar_1, except with signer == "bar_i"
and owner == "foo.bar_i" (rather than a fixed bar_1 and foo.bar_1)

Then, notice the following pattern:
If the RRset + RRSIG (or NS + DS) for foo.bar_1 is copied to foo.bar_k
(where k is 2 through N), then there will always be a valid RRSIG in the set
of RRSIGs, where the RRSIG was S_foo_k.

Which is to say, if we merge the zone data plus all the possible signatures
together, we can use the combined result in all the alias locations.

In the case of RRSIGs, that doesn't necessarily buy us much, other than
making some aspects of provisioning a bit easier.

However, in the case of DS, it may provide a significant benefit.

By calculating all the DS values, and inserting the union of those in all
parent zones, we don't have to worry about matching parent to child.
And, in the case of a zone parents being a zone with "sameness" applied,
through whichever mechanism happens to be used, the DS set is guaranteed to
work in *all* instances, *regardless* of means of making things "the same".

Since the name matching happens first, and the comparison is simple string
comparisons, the overhead is much less than having to try the cryptography
or hashing.

This may solve the iterative/recursive challenge to some of the proposals
(e.g. SHADOW).

And solving the hierarchical issue is key to solving the scaling problems
with "sameness" (IMHO).

--

Let's keep coming up with ideas that can provide tools or tweaks...

Brian