Re: [DNSOP] new dnsop related draft: RFC5011 security considerations
Matthijs Mekking <matthijs@pletterpet.nl> Thu, 04 August 2016 08:37 UTC
Return-Path: <matthijs@pletterpet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFFB12D6B2 for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2016 01:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YNJ44nfusbK for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2016 01:37:19 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4C812D095 for <dnsop@ietf.org>; Thu, 4 Aug 2016 01:37:18 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 0E6F28005; Thu, 4 Aug 2016 10:37:16 +0200 (CEST)
Received: from [IPv6:2001:981:19be:1:4436:b4cf:a460:2d6a] (unknown [IPv6:2001:981:19be:1:4436:b4cf:a460:2d6a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0235A8001; Thu, 4 Aug 2016 10:37:14 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: Wes Hardaker <wjhns1@hardakers.net>
References: <0lfuqoqhd7.fsf@wjh.hardakers.net> <99f615b9-15e6-d034-3926-83e273df6870@pletterpet.nl> <0lvazhhhxe.fsf@wjh.hardakers.net>
From: Matthijs Mekking <matthijs@pletterpet.nl>
X-Enigmail-Draft-Status: N1110
Message-ID: <2df5d3dd-7e71-6650-5011-d919bcc6e886@pletterpet.nl>
Date: Thu, 04 Aug 2016 10:37:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <0lvazhhhxe.fsf@wjh.hardakers.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5XRl1AwlHwaFskHAT9fyY7p698E>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] new dnsop related draft: RFC5011 security considerations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2016 08:37:21 -0000
Wes, On 08/03/2016 07:38 PM, Wes Hardaker wrote: > Matthijs Mekking <matthijs@pletterpet.nl> writes: > >> 1. In the introduction you mention there is no guidance to how long a >> DNSKEY must be published before it can be considered accepted. Perhaps >> there is no implicit guidance in RFC 5011, you should be able to derive >> it from the timing parameters defined in that document. > > I believe one can derive it, hence the reason we titled the draft > "security considerations". IE, it's not the intent of the draft to > create anything new, just to more clearly document what is already true > (but misunderstood by most). > >> In fact, it has been done before and RFC 7583 (DNSSEC Key Rollover >> Timing Considerations) gives guidance on exactly this in Section >> 3.3.4. > > I need to study that document again (it's been a while) in order to > fully respond to your note, but I agree there is information in there > that is certainly relevant. And we should certainly add a reference to > it as well, if this document needs to go forward. > > In 3.3.4.1, we have: > > modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2)) > Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval Looking at this advice again, I think the Zone Maintainer in the outlined attack actually even makes a conservative assumption about when it is safe to use the new key (T-36). If the Zone Maintainer followed the guidance in Section 3.3.4.1 from RFC 7583, it would have at least waited Itrp. The AddHoldDownTime is 30 days already in your example, see RFC 5011: The add hold-down time is 30 days or the expiration time of* the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater. * Side tracked: This 'of' should probably be an 'or'. Or I don't know what 'the expiration time of the original TTL...' means. The modifiedQueryInterval in your example is MAX(1hr, MIN(15 days, 1d /2)) = MAX(1hr, 1/2 day) = 1/2 day So already at T-31 the Zone Maintainer could have believed that all 5011 enabled validators should have accepted the new key. Now RFC 7583 makes this remark: Once retrieved, a validating resolver needs to wait for AddHoldDownTime. Providing it does not see a validly signed DNSKEY RRset without the new key in that period, it will treat it as a trust anchor the next time it retrieves the RRset, a process that can take up to another queryInterval (the third term). So Itrp does indeed not take into account this attack possibility. > And in our document, I just realized, fails to define the "safe" > equation that we came up with. But our safe value came out to be: > > Itrp >= AddHoldDownTime + 3 * SignatureLife / 2 + 2 * TTLkey Which in this example is 30 + 15 + 2 = 47 days. Since the replay attack is not possible anymore after the signatures at T-1 (or before) are expired, I think the new Itrp should be: Itrp >= SIGVALkey + AddHoldDownTime + 2 * modifiedQueryInterval ...where SIGVALkey is the RRSIG Signature Validity period of the DNSKEY RRset, used at T-1. > We'll go add that equation into our document (which I was sure we had > put in, but apparently not) and republish shortly. > >> 2. The outlined attack is possible because the defined queryInterval is >> approximately done at the half of the RRSIG expiration interval. If the >> queryInterval was to be increased that it would be at most the full >> expiration interval, the replay attack cannot be successfully executed. >> While this makes the DNSKEY rollover duration even longer, it is now >> secured against the outlined attack. > > I don't think we need to modify 5011 itself. Just how to use it. True. It's a matter of how one wants to fix it: With zone management to deal with the attack, or with updating the protocol so the attack cannot take place. I think the latter is more robust, but it's certainly good advice to increase the publication time of the DNSKEY to circumvent the attack. Best regards, Matthijs
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Shane Kerr
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Matthijs Mekking
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Warren Kumari
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Michael StJohns
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Matthijs Mekking
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Matthijs Mekking
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Bob Harold
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wessels, Duane
- [DNSOP] new dnsop related draft: RFC5011 security… Wes Hardaker