Subject: [DNSOP] Comments on draft-wessels-dns-zone-digest-02

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Aug 2018 14:19:08 +0000

FWIW, this message was spurred by this comic strip [yes, today as I write]: http://dilbert.com/strip/2018-08-09.

"Will the time taken to generate and verify this record add to the security of a zone transfer?"

I understand that there is no protection for cut point or glue records now, nor any guarantee for the occluded records and there's a desire to cover them.  It would be great to have the whole zone (as a data structure) be subject to source integrity and authenticity protections.

But there are already mechanisms for this at the data set level.  (This is a "belts and suspenders" style argument.)  What if -err- when, in a zone's distribution, the glue records are either forged or simply fat-fingered?  That's covered, in a way that is more efficient - in a lazy evaluation way.  Mangled glue never referenced needs not be checked, when it is needed there's backup in the authoritative version.  If all else fails, DNSSEC will flag whatever response as suspect.

I don't know if this is documented, but at one time, prototype authoritative servers would validate all the signatures in a zone upon load (before setting the AD bit).  This was discarded as it made zone loading (and reloading) take f-o-r-e-v-e-r.  (I recall this mostly because I was on the losing end of the argument.)  Today, we assume the server can set the AD as it can trust what it gets from disk or from AXFR {which had better be done with channel security!}.

One concern is what or who makes the decision to enable ZONEMD for a zone.  We are marching toward more automation in NOCs, so this will be a buried parameter.  What happens if a zone grows astronomically over time, in the beginning the ZONEMD is on?  (Similarly, zone have had to transition from NSEC to NSEC3 with optout.)  File this under "fear, uncertainty or doubt" but it stems from how I see the operations of the DNS evolving.

In general, the proposal is more or less fine.  I don't know if it is feasible (speed of execution).  I don't know that it adds to the safety of the system (DNSSEC already protects at the data set level in the same manner this protects at zone load time).  I don't know if the added configuration knob is justified by the benefit (forgotten settings, "trusted-keys"-mania ?).

And ... returning to the comic strip ... "Your plan is dumb because it reminds me of something different that didn't work out." ;)  "History repeats."  And today I am wearing a blue shirt (but it's a Knot DNS shirt!).

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Aug 2018 20:21:52 -0400

> FWIW, this message was spurred by this comic strip [yes, today as I write]: http://dilbert.com/strip/2018-08-09.

Cute.

> "Will the time taken to generate and verify this record add to the security of a zone transfer?"

Perhaps a sensible way to secure zone transfer is at the transport
layer.  Presumably DNS over TLS is comaptible with AXFR.  If desired
authentication can be via DANE.  Just publish a TLSA RRset:

	example.net. IN SOA nsa.example.net. hostmaster.example.net. ...
	example.net. IN NS nsa.example.net.
	nsa.example.net. IN A 192.0.2.1
	_853._tcp.nsa.example.net. IN TLSA 3 1 1 fbefbd9e5b54696792bab92cf329669edaca16d0b09dcfdd16fe3e1bd8ab08e9

and do the AXFR transfer over TLS.  This does not require pre-computation
of a zone checksum.  Just obtain the zone transfer from a suitably
trusted source.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Aug 2018 20:24:04 -0400

The point was to allow redistribution and to not depend on a trusted source 

Sent from my phone

> On Aug 9, 2018, at 20:21, Viktor Dukhovni <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Aug 2018 13:18:05 +0000

>The point was to allow redistribution and to not depend on a trusted source 

That, FWIW, is the heart of DNSSEC.  Source authentication and data integrity for data sets is the advertised goal (as well as provable non-existence) of the extensions.  The DNS is not a strict client-server protocol, there is no telling what path a resource record (set) would take from the zone administrator to the would-be validating receiver.

Originally the set of paths included authoritative servers, forwarding servers, recursive servers, iterative servers, and such down to the point where DNSSEC validation could no longer be done.  (Originally, CPU horsepower and reliable libraries weren't assumed to me on end devices, hence the stub resolvers aren't included.  No reason they couldn't, no reason applications can't validate, except for performance/trust anchor management concerns.)

Now we are envisioning the transfer of zones in bulk, not just single datasets, via non-port 53 means.  But is that any different?  Does it really matter whether RSYNC of a zone was used to get a dataset from A to B?

There is a concern I can see.  When a server is loaded from disk (secondary storage), it does not validate the DNSSEC records to save time.  There's a risk that a maliciously inserted zone version be loaded and served, possible if the channel security is defeated.  But, if that happens, validating recipients of data sets will fail the data sets that are altered.  While this could be a denial of service for the server, but DNS provides fallback to other servers so relying parties are just as protected as they ordinarily are (including, no DNSSEC, no protection...).

How realistic is it that a forged zone could defeat all of the channel security for a zone?  How likely would it be for someone to load a false zone on all the places a recursive server would look for it?  Answering that would be a crucial step in deciding whether to add a zone hash mechanism.

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 10 Aug 2018 07:10:28 -0700

> The point was to allow redistribution and to not depend on a trusted 

We don't know that. After the wide-ranging list discussion, it would be 
great if the document authors were clearer on what the point is / points 
are in a new draft. Until then, we're only guessing about what the use 
cases are and are not.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 10 Aug 2018 19:09:24 +0000

> On Aug 9, 2018, at 7:19 AM, Edward Lewis <[email-masked]> wrote:
> 

Hi Ed,

> "Will the time taken to generate and verify this record add to the security of a zone transfer?"

I think "security of a zone transfer" is too narrow, although perhaps you didn't mean it so literally. For me, its about improving the security of the data in a zone file, regardless of how you get it and, to some extent, regardless of how you use it.  

> I understand that there is no protection for cut point or glue records now, nor any guarantee for the occluded records and there's a desire to cover them.  It would be great to have the whole zone…

Agreed.

> But there are already mechanisms for this at the data set level.  (This is a "belts and suspenders" style argument.)  What if -err- when, in a zone's distribution, the glue records are either forge…

Yes, certainly DNSSEC protects from modification of answers.  It generally protects recursives who validate.  But it doesn't protect consumers of zone files.

Another limitation I've mentioned before, where DNSSEC doesn't protect you, is that a delegation could be falsified such that traffic goes to an eavesdropper that just records but doesn't modify messages.  

> I don't know if this is documented, but at one time, prototype authoritative servers would validate all the signatures in a zone upon load (before setting the AD bit).  This was discarded as it mad…

I'd also argue that maybe applications shouldn't necessarily trust a file just because its "on disk." The application doesn't know how it got there, or what may have been done to it.

> One concern is what or who makes the decision to enable ZONEMD for a zone.  We are marching toward more automation in NOCs, so this will be a buried parameter.  What happens if a zone grows astrono…

I'd say that decision lies with the zone owner or operator, and it would make me sad if fear over the very very rare case of astronomical growth was a reason for not doing this.

> In general, the proposal is more or less fine.  I don't know if it is feasible (speed of execution).  I don't know that it adds to the safety of the system (DNSSEC already protects at the data set…

I'm not sure this is what you mean by "speed of execution" but as an example, my implementation (which uses ldns) can calculate and verify a SHA256 signed root zone digest in under 100 msec.

$ sort --random-sort root.zone.signed | ldns-zone-digest -t -p 2 -c -v . 
Loading Zone...22539 records
Remove existing ZONEMD...
Add placeholder ZONEMD...
Calculating Digest...Done
Calculating Digest...Done
Found and calculated digests do MATCH.
TIMINGS: load  142.18 calculate   82.72 verify   52.24 update    0.00

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 10 Aug 2018 19:10:35 +0000

> On Aug 10, 2018, at 7:10 AM, Paul Hoffman <[email-masked]> wrote:
> 
> We don't know that. After the wide-ranging list discussion, it would be great if the document authors were clearer on what the point is / points are in a new draft. Until then, we're only guessing about what the use cases are and are not.
> 

Thanks Paul,

Yes we are working on new version based on the list discussion.  

DW

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Aug 2018 16:41:18 -0400 (EDT)

> Yes, certainly DNSSEC protects from modification of answers.  It generally protects recursives who validate.  But it doesn't protect consumers of zone files.

By design....

> Another limitation I've mentioned before, where DNSSEC doesn't protect you, is that a delegation could be falsified such that traffic goes to an eavesdropper that just records but doesn't modify me…

but on most networks you connect to that you don't trust, they could
just be monitoring all your port 53 traffic anyway? I don't see this
much as a use case. An attacker that cannot see your traffic, but could
get to see your DNS root queries but only briefly if you cache or
actually use the root zone you just transfered from them. Also query
minimalization makes that use case very uninteresting.

> I'd also argue that maybe applications shouldn't necessarily trust a file just because its "on disk." The application doesn't know how it got there, or what may have been done to it.

Sure but applications should either validate or trust the local
validator loading the zone. So that limits the discussion to
glue/NS only.

> TIMINGS: load  142.18 calculate   82.72 verify   52.24 update    0.00

I don't see it validating the ZONEMD RRSIG here ? :P

Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 10 Aug 2018 23:22:22 +0200

Paul, you seem suspicious that there is some underhand camel attack
being planned, here, and that the forces of good must assemble to
reveal the ugly truth and save the caravan.

I think being able to verify the integrity of a zone as a complete
data structure is useful.

I think interop is useful.

I think this specification is pretty good.

I think stable specifications promote interop and make things like
this more useful.

Your objections seem to boil down to: I don't like this; I'd achieve
the kinds of things you want to achieve in other ways. That seems like
useful input to a document that discusses the relative merits of doing
things in many ways; that's not what this document is about, though.

So I must be missing something because I don't understand what you're
objecting to.

> On Aug 10, 2018, at 16:41, Paul Wouters <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 10 Aug 2018 18:06:05 -0400

In article <[email-masked]> you write:
>How realistic is it that a forged zone could defeat all of the channel security for a zone?  How likely would it be for
>someone to load a false zone on all the places a recursive server would look for it?  Answering that would be a crucial step
>in deciding whether to add a zone hash mechanism.

Since the obvious use case for this is to enable zone distribution
over insecure channels, such as FTP or bittorrent, I'd say it's
completely realistic.

R's,
John

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 13 Aug 2018 15:49:24 +0000

Thanks Paul,

DW