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

Matthijs Mekking <> Mon, 11 September 2017 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0976013232C for <>; Mon, 11 Sep 2017 04:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 18_cTO-3JtUF for <>; Mon, 11 Sep 2017 04:59:43 -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 1D74D132D22 for <>; Mon, 11 Sep 2017 04:59:43 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:58a:2293:1451:51da] (unknown [IPv6:2001:981:19be:1:58a:2293:1451:51da]) by (Postfix) with ESMTPSA id 1BDB7BA9C for <>; Mon, 11 Sep 2017 13:59:41 +0200 (CEST)
Authentication-Results:; dmarc=none
References: <> <> <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Mon, 11 Sep 2017 13:59:40 +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: Mon, 11 Sep 2017 11:59:45 -0000


On 06-09-17 18:05, Wes Hardaker wrote:
> Matthijs Mekking <> writes:
> Thanks for all your points, and I've gone through and handled them all
> in the text (including discussing that we update 7583 per your request).
>> 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).
> This is the one that had me think with a whiteboard for a while.  If I
> can sum it up differently, the problem is that 30 days may not be a
> factor of the queryInterval.  Thus:

But it is:

queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,

Since the 5011-enabled resolver should see at least two queries with the
new trust anchor, the 15 days (30/2) is in the above equation defined in
RFC 5011.

>     N * queryInterval >= >
> Where N is the number of queries to get somewhere over 30 days.

Sure, but N does not need to be higher than two, and in that case:

    2 * queryInterval = MAX(2 hr, MIN (30 days, OrigTTL,

In other words, never more than 30 days.

> So Irtp is waiting an extra queryInterval to account for this
> possibility.

Right, and since it is a possibility, it should be taken into account.

An important observation is that once the add hold-down timer expires,
the new key will be added as a trust anchor *only* the next time the
validated RRset with the new key is seen at the resolver.

This is the reason why the second queryInterval must be part of the

> Mathematically, I think the actually time needed to wait is 30 %
> queryInterval, which may actually be 0 in some cases and just shy of
> queryInterval in others.  Sound about right?

I am sorry, I don't understand this logic, can you elaborate?

The way I see it, queryInterval is always at minimal 1 hr and at most 15
days (not taking into account retryTime).

Best regards,

>> 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.
> I'll have to add some text about that.  I don't think we can solve the
> case for broken networks, though.  But it's an important point to bring up.