On 30 Jul 2018, at 16:12, Evan Hunt wrote:
On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote:
I am still mystified about the scenario in which a malicious zone
operator creates two zone files with the same ZONEMD hash, one with
the
right set of addresses for unsigned child zones, and a different one
with one of more of those child zones with wrong addresses plus
enough
other kruft to make the colliding hashes match. In what world is that
attack more likely than just not using ZONEMD?
I don't think the imagined attack involves a zone operator creating
two
zones. It would be a zone operating creating one zone, with a
legitimate
and validly signed ZONEMD, and then someone else creating a fake
version
of the zone in which all the signed rrsets still validate, and the
ZONEMD
still matches, but the unsigned parts have been mucked with.
But that can't happen with any of the hash algorithms allowed by the
draft. What you are describing is a second preimage attack, and no
modern hash algorithm (not even MD5!) has any known second preimage
weaknesses.
The bit that started this thread was a concern about collision attacks.
Collision attacks can only be mounted by the person who creates the
hash, by creating two messages that both have the same hash. The
suggestion was to not allow hash algorithms that had known collision
resistance reductions (such as MD5 and SHA1), which is fine in general.
However, as people went on and on about how to make further changes to
the RRtype, I questioned what collision attack they were thinking of.
Adding an RR
count does make that attack more expensive. I'm not sure it makes
enough
difference to be worthwhile.
Exactly.
Another imagined attack is someone trying to dump terabytes on you
when
initiate the zone transfer. An RR count could help with that, if you
looked it up before starting the transfer.
See above. If you are blindly accepting terabytes of data from a trusted
source, you have other problems.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
