Subject: [DNSOP] Incremental zone hash - XHASH

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Jul 2018 20:31:07 +1000

Rather than having a full zone hash this can be done as a chain
of hashes (XHASH).

The XHASH would include all records at a signed name (where a signed
name is NOT an NSEC3 name) up until the next signed name (where a
signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD.
If there is a NSEC3 record and its RRSIGs in this range it is included
in the hash computation.  Where a NSEC3 record matches the name of a
record that exists in the zone it is hashed with that name. The record
type appears at both top and bottom of zone similar to NS.

The chain is only deemed to be complete if there is a hash record at
the zone apex. This allows for incremental construction and destruction
of the XHASH chain similar to the way the presence of NSEC at the zone
apex indicates that chain is complete.

If there are records that are not at or under the zone apex they are included
in the final XHASH of the zone sorting from the zone apex to the end of the
namespace then from the start of the namespace to the zone apex. Such records
at not normally visible to queries other than AXFR/IXFR.  AXFR/IXFR permit such
records. 

XHASH would allow for UPDATE to incrementally adjust the chain without
having to hash the entire zone at once.

XHASH would allow for a slave server to verify a zone is still complete
after a IXFR by just checking the areas of the zone impacted by the IXFR.

e.g.

	example.com SOA
	example.com NS ns.example.com
	example.com DNSKEY …
	example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH
	example.com XHASH …

	a.example.com NS ns.a.example.com
	a.example.com NSEC b.example.com NS RRSIG NSEC XHASH
	a.example.com XHASH …
	ns.a.example.com A …

	b.example.com NS ns.b.example.com
	b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH
	b.example.com XHASH …
	ns.b.example.com A …

	ns.example.com A …
	ns.example.com AAAA …
	ns.example.com NSEC example.com A AAAA RRSIG NSEC XHASH
	ns.example.com XHASH …

Each of the groupings shows which records plus RRSIGs that are
included in the XHASH calculation.

To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY
flag bit is be needed to indicate which RRSIG(XHASH) should/should not
be present once the chain is complete.  The same applies to RRSIG(ZONEMD).

Verification of a AXFR would be slightly slower than with ZONEMD as there
are more RRSIG records to be processed,

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Fri, 20 Jul 2018 08:37:23 -0400

The intent (to me at least) is to be able to use exterior fetch, *not*
DNS, to source this as a file. curl. wget. ncftp. rsync.

the "thing" is a file object. It almost certainly is in near-canonical
sort order already. Its a stream of characters, probably in
bind-normal form.

If you can compute the path through the labels and the chain of NSEC
regions and the expected hadda-yadda-dadda.. you don't *need* a
digest.

If you have a digest, and its already in near canonical order, then
*cost* to compute "is the file exactly as the publisher wrote it" is
low. And, since its a signature under the ZSK, its not just "its as
the publisher said" its "the publisher knows the ZSK" which is strong
enough to say: "just load it"

So, I ask: is this incremental method applicable to this model?

Sure, works for giant zone. What about a root zone? Do I need this?

Also.. glue.

-G

On Fri, Jul 20, 2018 at 6:31 AM, Mark Andrews <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Sat, 21 Jul 2018 00:14:02 +1000

> On 20 Jul 2018, at 10:37 pm, George Michaelson <[email-masked]> wrote:
> 

Nothing in this proposal stops these transport mechanisms.

> sort order already. Its a stream of characters, probably in

Which is basically DNSSEC order.

> regions and the expected hadda-yadda-dadda.. you don't *need* a
 
The difference between METAMD and XHASH is that you do XHASH in smaller
chunks on such a ordered zone and verify each chunk as you go through.

> So, I ask: is this incremental method applicable to this model?

Yes

> Sure, works for giant zone. What about a root zone? Do I need this?

Yes, it works for the root zone.

> Also.. glue.

Yes it hashes glue and delegating NS record.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 21 Jul 2018 00:32:39 +1000

The same zone NSEC3 signed with a.example.com in OPTOUT range

	example.com SOA
	example.com NS ns.example.com
	example.com DNSKEY …
	example.com NSEC3PARAM 1 0 0 -
	example.com XHASH …
        3QNILC4QRC2P5CRN7JGVB5S3BPG0SHUV.example.com 1 1 0 - NSEC3 1 1 0 - ONIB9MGUB9H0RML3CDF5BGRJ59DKJHVK.example.com NS RRSIG XHASH
	a.example.com NS ns.a.example.com
	ns.a.example.com A …

	ns.example.com A …
	ns.example.com AAAA …
	ns.example.com XHASH …
	ONIB9MGUB9H0RML3CDF5BGRJ59DKJHVK.example.com NSEC3 1 1 0 - PTJ67J96LVVVBU5K3V6N10B6QMO17275 NS SOA RRSIG DNSKEY NSEC3PARAM XHASH
	PTJ67J96LVVVBU5K3V6N10B6QMO17275.example.com NSEC 1 1 0 - 3QNILC4QRC2P5CRN7JGVB5S3BPG0SHUV.example.com A AAAA RRSIG XHASH

---

From: Paul Vixie <[email-masked]>
Date: Fri, 20 Jul 2018 20:01:09 +0200

perfect!

-- 
P Vixie

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 20 Jul 2018 23:38:43 +0000

Mark,

Thanks for the email.

My first reaction is that it adds a lot of additional records to the zone.  If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for each XHASH.  You didn't really say how (or if) XHASH could be used on an unsigned zone.

My second reaction is that it is (necessarily) more complex than what we proposed with ZONEMD.  It seems like it probably works, but I haven't really spent time thinking about it in depth.

The use case that my coauthors and I are trying to address with ZONEMD is to verify authenticity for relatively stable zones being distributed to servers other than the ones in the NS RRset.  For this XHASH feels like too much.  Too much data and too much complexity.  I'm not sure if you're proposing XHASH as an alternative to, or in addition to, ZONEMD.

If the latter then I'd say get input from operators of dynamic zones and see if they think the tradeoff of extra data and complexity is of net benefit to them.

DW

> On Jul 20, 2018, at 3:31 AM, Mark Andrews <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Sun, 22 Jul 2018 14:51:12 -0400 (EDT)

> DNS, to source this as a file. curl. wget. ncftp. rsync.

So pull it over HTTPS/TLS and you are good? No bits will be allowed to
be flipped without the transport security freaking out.

If you are looking at additional trust on the data, we have DNSSEC. If
you are concerned about glue/NS being unsigned and modified at the
source, then you need some kind of signature over the data that the
web server cannot modify.

I see no reason why this should be an RRTYPE though. Especially one that
can only work in weird automated ways of generating a signature over a
file which you then modify to add the signature in.

Especially since using an RRTYPE means you are fully relying on DNSSEC
as the pubkey for signing the data. And if you use DNSSEC, why care
about unsigned data?

>> Verification of a AXFR ....

Since you dont want to mandate the DNSSEC key on the server serving the
data, it has to be some external key/checksum/transport security, which
we already have for *XFR permissions? If *XFR doesn't use that for
glue/NS, can we not just add a a checksum here based on the XFR keys?

ZONEMD and XHASH seem to be the wrong hammers to use here, unless I
misunderstood the problem?

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Jul 2018 12:30:03 -0400

> misunderstood the problem?

One of the original promises of DNSSEC is that I'd be able to find a
zonefile written on a napkin on a bar floor, and trust it -- currently
I cannot do this.

As an example, let's say we'd like to distribute the rootzone over
BitTorrent to people who want to do LocalRoot - how do they know they
can trust the zone file before loading it? Or, in a less crazy
example, distribute it over some set of CDNs - being able to know that
you have the full, and correct zone without having to walk the NSECs
and hope that the glue is correct would (IMO) be nice.
Coordinating keys with just anyone who does an AXFR of a public zone
is not really viable.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Jul 2018 13:03:39 -0400

> zonefile written on a napkin on a bar floor, and trust it -- currently

I don't think this is correct.

The main thrust of DNSSEC (as finally standardised) was to protect caches from poisoning -- in other words, to protect responses with cryptography.

Zone files contain things that are not responses, but are used to obtain responses (like glue records, NS RRSets above a zone cut). I don't think it was ever a design goal to sign those, and hence it wasn't a design goal to sign zones in the way that you describe.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Jul 2018 13:09:14 -0400 (EDT)

> zonefile written on a napkin on a bar floor, and trust it -- currently

That's a harder problem :P

> and hope that the glue is correct would (IMO) be nice.

Once you validate the ZONEMD, it is not that much more dificult
than running over all the records, eg with validns or ldns-read-zone.

Although you could skip it and let DNSSEC failures deal with any
potential records who were modified by an attacker that doesn't have
the private key of that zone.

That leaves glue and NS, but there is a reason those aren't signed,
and any attacker shouldn't get anything out of that by modifying it.

(other then a DDOS, but they can always do that if they control your
zonefile download)

If you do want all of that protected, which I don't think there are
strong reasons for, why not place an OPENPGPKEY record in the zone and
use pgp to sign it? No new custom software needed, and equally
annoying validing the OPENPGPKEY as the ZONEMD data.

Inventing a file checksum for DNSonly data seems a suboptimal custom
solution to me (too much hammertime)

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 25 Jul 2018 17:59:51 +0000

> On Jul 25, 2018, at 10:09 AM, Paul Wouters <[email-masked]> wrote:
> 

What new custom software are you thinking of?

One of my expectations is that ZONEMD would be implemented in name server software.  That software already includes code to calculate hashes and verify DNSSEC signatures.  AFAIK no name server software knows how to verify pgp signatures.

(Admittedly perhaps missing from some current name server software is code for canonical sorting.)

DW

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jul 2018 05:20:11 +0200

Duane,

> My first reaction is that it adds a lot of additional records to the zone.  If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for each XHASH.  You didn't really say how (or i…

What if the ZONEMD+RRSIG would be hash of the XHASH records?  That way the XHASH records could stay unsigned.

> My second reaction is that it is (necessarily) more complex than what we proposed with ZONEMD.

It might seems there is an additional complexity from the protocol description, but I don’t think it there’s much difference on the implementation level.  You need to sort and walk the zone for ZONEMD in the same manner as you would for XHASH.  It only differs in an record(s) where you dump and reset the computed hash.

Ondrej
--
Ondřej Surý
[email-masked]

> On 21 Jul 2018, at 01:38, Wessels, Duane <dwessels=[email-masked]> wrote:
> 
> Mark,
> 
> Thanks for the email.
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Jul 2018 16:52:49 -0700

> and any attacker shouldn't get anything out of that by modifying it.

Yes, the glue isn't authoritative and thus not signed by DNSSEC.

But, if you're transferring a zone from an original source to any
secondary server that is redistributing the contents, then modification
by an attacker can certainly do damage (though with fully deployed
DNSSEC, it may be only a DOS; though without fully deployed it's much
worse, and we're a long way from fully deployed on both ends).

The question of need comes down to: regardless of how it's done, do we
need a global zone data signature across the entire set of distributed
data that survives multiple distribution hops.  From the perspective of
wanting to distribute data across a multitude of mechanisms (including
DNS but all git, bittorrent, http, and Warren's dirty napkin), then
there is value to having a verifiable checksum.  That's why software
packages are distributed in the same way: verify that what you got is
authentic before using it.

-- 
Wes Hardaker
USC/ISI