> On Aug 9, 2018, at 7:19 AM, Edward Lewis <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
