[dns-operations] [Ext] Re: help with a resolution
Viktor Dukhovni
ietf-dane at dukhovni.org
Wed Jan 8 22:10:20 UTC 2020
On Wed, Jan 08, 2020 at 09:00:26PM +0000, Paul Hoffman wrote:
> I'm with Warren: I don't see how the chosen-prefix collision affects DNSSEC.
And yet it does, because signatures over a benign RRset A, may also be
valid signatures for a malicious RRset B, where A and B don't share the
same (owner, type, class) triple. If I can get you to sign A, you may
be inadvertently also signing B.
> > 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).
>
> True, but irrelevant. An attacker can create a DNSKEY RRset for something
> they don't control already today.
Not as a signed RRset with a key they created for my zone, where I was
only willing to sign a TXT record for a node they they are authorized to
control (authenticted admin control over a subtree of a zone, without
there being a delegation cut). For now, it looks like DS RRsets are
safe, but that could change as attacks improve to the point of making
it possible to create an attack with a 256-bit suffix (rather than 9
to 10 SHA-1 blocks or 1440--1600 bits).
> > 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).
>
> A DNSKEY RR is only useful if there is a matching DS in the parent
> zone that matches the DNSKEY. In your scenario, that would require a
> preimage attack.
No, that's false. The DNSKEY RRset in question would be for the
zone apex, and match one of the zone's KSKs, but carry other keys
of the attacker's choice.
--
Viktor.
More information about the dns-operations
mailing list