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

Reply via email to