Re: [DNSOP] Incremental zone hash - XHASH

[Paul Wouters <[e-mail]>]

On Fri, 20 Jul 2018, George Michaelson wrote:

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

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