[Yeti DNS Discuss] Theoretical DoS attack during KSK roll

Kees Monshouwer keesm at monshouwer.eu
Mon Sep 5 17:29:35 UTC 2016


Hello Shane,

they must be reading the yeti list ;)

http://lists.yeti-dns.org/pipermail/discuss/2016-July/000664.html

With kind regads,

Kees Monshouwer

On 09/05/2016 05:30 AM, Shane Kerr wrote:
> Hello,
>
> RFC 5011 DoS 
> ------------
> Recently Wed Hardaker and Warren Kumari submitted a draft describing a
> denial-of-service attack on zones using RFC 5011:
>
> https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-01
>
> The basic problem is that an attacker can replay an earlier version of
> the signed DNSKEY RRset until the signatures expire. A resolver that
> sees the old DNSKEY RRset  will re-start the 30-day RFC 5011 hold-down
> timer.
>
> This means that an authority server has to add the DNSKEY RRset
> signature validity time to the 30-day timer (along with the TTL),
> otherwise when it starts using the new KSK the resolver will not have
> accepted the KSK, and validation will fail.
>
> RFC 5011 DoS & Yeti
> -------------------
> In our current Yeti KSK roll we ARE VULNERABLE to this DoS. We have a
> 1-month signature validity period (!!), and have already revoked our
> old KSK after only a 32-day wait.
>
> We did not extend the current experiment for a few reasons. It would add
> another 28 days (or more?) to an already long experiment, plus we would
> be changing the experiment in the middle. Also, the risks of the attack
> are real but low - they require either an on-path attacker or something
> like a Kaminsky attack. The damage of the attack would be a Yeti
> resolver stops working, which would be unfortunate but since Yeti
> resolvers are opt-in we hope that they are generally run by clueful
> operators who can fix it quickly (either by updating the KSK manually
> from the Yeti website, converting to the IANA KSK, or by disabling
> DNSSEC).
>
> Signature Validity and the Root
> -------------------------------
> I think that we (Yeti) should reduce our signature validity period. We
> generate a new version of the zone 2 times per day, and we have a 1 day
> TTL. There is no reason for a signature validity period of longer than
> 2 days, or maybe 3 days to allow for clock drift on resolvers.
>
> This would require the Distribution Masters (DM) change their signing
> parameters, and we may want to consider changing the expire time on the
> root zone SOA record (currently 1 week).
>
> Note that the IANA root has a 2-week signature validity. This is also
> longer than it has to be, because of the IANA root is also generated 2
> times per day and has a 2 day TTL. While not vulnerable to the RFC 5011
> DoS described (because of the long rolling periods for the IANA root),
> a longer signature validity than necessary does open some window of
> vulnerability to replay attacks, and perhaps this should be reduced.
>
> Certainly for the IANA root a 1-week signature validity is completely
> safe and would cut the replay window in half. The expire time on the
> IANA root zone SOA record may need to be changed here too.
>
> Possible RFC 5011 DoS Experiment
> --------------------------------
> We should be able to test the DoS on Yeti. The proposal is basically
> that we replay some old DNSKEY records to specific resolvers in order
> to reset their hold-down timers. This means that we would leave the
> Yeti KSK vulnerable for a period during the next KSK roll as well.
>
> For the next KSK roll we can DoS specific test resolvers by re-playing
> the old DNSKEY during the first 3 days after the experiment starts,
> which should reset their RFC 5011 hold-down timer, and then we can
> observe them failing resolution when we roll to the new KSK at the end.
>
> For future KSK roll we will extend the time before using the new KSK to
> also account for the signature validity period, removing the
> vulnerability.
>
> Cheers,
>
> --
> Shane
> _______________________________________________
> discuss mailing list
> discuss at lists.yeti-dns.org
> http://lists.yeti-dns.org/mailman/listinfo/discuss




More information about the discuss mailing list