[dns-operations] help with a resolution
Viktor Dukhovni
ietf-dane at dukhovni.org
Wed Jan 8 20:18:09 UTC 2020
On Wed, Jan 08, 2020 at 02:53:42PM -0500, Warren Kumari wrote:
> Can someone please explain to me in baby words how the SHA-1 issue affects
> DNSSEC? [...] but SHA-1 is still 2nd-preimage resistant - given the hash
> a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find another
> message which hashes to this.
That's still true, but the attack leverages chosen-prefix collisions against
signatures, in which the tail of the data signed is controlled by an attacker.
Not 2nd pre-image attacks on a hash of a trusted message.
> So, I *could* see an attacker being able to make 2 records or keys
> which have the same hash -- but, meh, that's not actually useful to
> them.
Well, there's your mistake, because with "chosen-prefix" attacks, the second
RRset being signed need not have the same owner or type, thus a weird TXT
RRset for a benign owner may SHA-1 hash to the same value as an attacker
selected DNSKEY RRset for the zone (that includes a KSK matching the DS
RR, but also keys controlled by the attacker).
> eg: The DS for dns-oarc.net is: 20899 8 1
> 6714FF6879371C5DC19BB0389F9D497520448A2E - an attacker cannot make a
> new key which hashes to this.
Yes, that's why I decided to follow up on Mukun'd post. Digest type
1 (SHA-1) in DS RRs is mostly harmless, though again not recommended.
> They could in theory make 2 DNSKEYs
> which have the same hash (although, because of the format of DNSKEYs I
> don't think they can do this in practice),
No, they could do much worse, they could make a TXT RRset, that
secretly matches a DNSKEY RRset (at least for a given signature
period, the collision will break once the RRset is resigned with
a different inception/expiration interval).
> I'm feeling like I'm missing something obvious here...
See above.
--
Viktor.
More information about the dns-operations
mailing list