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

["Wessels, Duane" <[e-mail]>]

> On Aug 9, 2018, at 7:19 AM, Edward Lewis <[e-mail]> wrote:
> 
> FWIW, this message was spurred by this comic strip [yes, today as I write]: http://dilbert.com/strip/2018-08-09.

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 (as a data structure) be subject to source integrity and authenticity protections.

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

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

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

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


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