Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[George Michaelson <[e-mail]>]

So if I look at what you said, what I see is "inband, canonicalization
is a cost we don't want to bear, to produce a signed product of whole
of zone" and "if we accept knowledge of a PGP or other external key as
the moment of trust, out of band, disordered but specifically testable
as *this file* is signed by *known key* is workable.

wow. Firstly, I thought canonicalization was a given: we have
definitions of canonical zone order for other reasons (NSEC*) don't
we?

secondly, I absolutely (and no sarcasm implied or intended, I really
mean it) applaud the pragmatism. If we can move to a world which
accepts the root is a resource which can routinely be fetched out of
band, validated out of band, and then locally bound to a DNS server,
we've probably moved on.

in-band is great. but, sometimes, its really hard.

So how about use of a PGP key which is a payload in TXT signed over by
the ZSK/KSK so the trust paths bind together?

fetch one DNS record +sigs, check against the TA (which has to be a
given) and then..

-G

On Mon, Jul 9, 2018 at 10:28 AM, Olafur Gudmundsson <[e-mail]> wrote:
>
>
> On Jun 22, 2018, at 6:58 AM, Petr Špaček <[e-mail]> wrote:
>
> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote:
>
> On 22:09 21/06, Shane Kerr wrote:
>
> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
>
> Hmm, can you share some details about your experience?
> Did you find out when the data corruption took place?
> a) network transfer
> b) implementation bugs (e.g. incorrectly received IXFR)
> c) on disk
> d) some other option?
>
>
> I don't know. I have seen incorrectly transferred zone files both in
> BIND
> and NSD slaves. IIRC our solution was to include sentinel records in
> the
> zone files to spot problems, take the node out of service, and force a
> re-transfer. This of course won't work if you are slaving zones that
> you do
> not control, and it doesn't prevent a small window of time when the
> servers
> are operating with broken zones. TSIG was being used.
>
>
> We have also seen broken transfers between secondaries. Our solution
> is to dump the zone after transfer, calculate a hash and compare. We
> would benefit from having a ZONEMD record inside the zone.
>
>
> If the zone got broken during TSIG-secured transfer then it was not most
> probably not caused by network problem because TSIG would have caught that.
>
> Honestly I do not think it is worth the effort because all the
> complexity does not help to prevent implementation bugs, I would say it
> even increases probability of a bug!
>
> What is left is bug on auth and/or slave sides and in that case there is
> no guarantee that
> a) master did not compute ZONEMD from already broken data
> b) slave verification of ZONEMD actually works
>
>
> If we wanted to catch problems with implementation we need something
> which is outside of the DNS stack we are attempting to check, be is
> simple checksum or some fancier crypto.
>
> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
> node and an utility which would extract OPENPGPKEY RR from the zone file
> and verify that the zone file signature (either detached or in .gpg
> file) can be verified using that key (+ add DNSSEC into the mix if you
> wish).
>
> --
> Petr Špaček  @  CZ.NIC
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
>
> +1
> I spent lots of time earlier this century along with Johan Ihren trying to
> figure out how to
> secure the transfer of a particular zone (the root) to any resolver.
> The only sane way is to not transfer the zone over AXFR as any intermediary
> can mess with the zone contents mostly in the case of “glue” records,
> thus transferring the zone over HTTPS or RSYNC with a PGP signature over the
> zone file is the only viable solution going forward.
>
>
> Historical background: SIG(AXFR) was rejected because it required putting
> the zone into canonical order and calculating the signature,
> in the case of dynamic update this is a real expensive operation, thus we
> got rid of it.
>
> Olafur
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>