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 <[email protected]> wrote: > > > On Jun 22, 2018, at 6:58 AM, Petr Špaček <[email protected]> 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 > [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
