Re: [DNSOP] requesting WGLC for 5011-security-considerations

Matthijs Mekking <> Thu, 20 July 2017 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E98A129AC4 for <>; Thu, 20 Jul 2017 05:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0V_AKqpdlCLC for <>; Thu, 20 Jul 2017 05:35:06 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id EFFA3131C17 for <>; Thu, 20 Jul 2017 05:34:59 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:50bf:8888:2e7c:bc75] (unknown [IPv6:2001:981:19be:1:50bf:8888:2e7c:bc75]) by (Postfix) with ESMTPSA id EDF47B5F7 for <>; Thu, 20 Jul 2017 14:34:57 +0200 (CEST)
Authentication-Results:; dmarc=none
References: <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Thu, 20 Jul 2017 14:34:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Jul 2017 12:35:13 -0000


It's been a while since I have had a look at this draft, my apologies.

I don't think it is ready for WGLC because I am not convinced the math
is correct. Section 6 defines the waitTime:

     waitTime = addHoldDownTime
                + (DNSKEY RRSIG Signature Validity)
                + MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,
                          MAX(original TTL of K_old DNSKEY RRSet) / 2,
                          15 days),
                      1 hour)
                + 2 * MAX(TTL of all records)

Which is the same as:

     waitTime = addHoldDownTime
                + (DNSKEY RRSIG Signature Validity)
                + queryInterval
                + 2 * MAX(TTL of all records)

but reads better.

This should be the same as Itrp as defined in RFC 7583:

      Itrp >= queryInterval + AddHoldDownTime + queryInterval

Basically these two differ at the following points:

1. Itrp does not include (DNSKEY RRSIG Signature Validity). It does
mention that the validator should not see a validly signed DNSKEY RRset
without the new key in that period. So adding (DNSKEY RRSIG Signature
Validity) is a good update.

2. waitTime only adds one queryInterval, while Itrp adds two. I believe
to be safe on the publishing side, two queryIntervals is needed. RFC
7583 explains:

   A validator 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).

3. waitTime adds two MAX(TTL of all records) (margin). The draft says
that it probably not needed, and I agree, and that explains why it is
missing from the Itrp definition.

4. Both definitions (Itrp and waitTime) don't really take into
consideration the retryTime defined in RFC 5011. Perhaps that can be
used for defining the extra safety margin.

5. Itrp actually is defined with a modifiedQueryInterval which excludes
the RRSIG expiration interval. Now this is recognized to be the time
between inception and expiration of the RRSIG, I actually think it does
not need to be removed from the equation. So Itrp could have worked with
just queryInterval.

Given these points I think the correct definition of waitTime is:

     margin = 2 * MAX(TTL)

     waitTime = addHoldDownTime
                + signatureValidity(DNSKEY)
                + 2 * queryInterval
                + margin

I think slop needs to be separated and it should be documented that this
is a suggested value for the slop.

Furthermore, this document should also give guidance on the wait time
before a revoked DNSKEY can be removed from the zone:

     waitRemoveTime = signatureValidity(DNSKEY)
                + queryInterval
                + margin

This document should probably update RFC 7583 because it is giving a
better definition of Itrp and Irev.

For readability of the document I would like to suggest to move the
Attack example and breakdown to the Appendix.

Kind regards,

On 05-07-17 19:11, Wes Hardaker wrote:
> Folks,
> We believe that the latest draft-rfc5011-security-considerations
> document is ready for WGLC, and would like the chairs to start that
> process unless anyone thinks it's not ready to go forward.  In
> particular, we believe all outstanding issues with it have been
> resolved.
> Objections?