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

Wes Hardaker <> Wed, 06 September 2017 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88178132031 for <>; Wed, 6 Sep 2017 09:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PF9cqze03DX9 for <>; Wed, 6 Sep 2017 09:05:44 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0BB6124207 for <>; Wed, 6 Sep 2017 09:05:44 -0700 (PDT)
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5B65A20C02; Wed, 6 Sep 2017 09:05:44 -0700 (PDT)
From: Wes Hardaker <>
To: Matthijs Mekking <>
References: <> <>
Date: Wed, 06 Sep 2017 09:05:44 -0700
In-Reply-To: <> (Matthijs Mekking's message of "Thu, 20 Jul 2017 14:34:56 +0200")
Message-ID: <>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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: Wed, 06 Sep 2017 16:05:45 -0000

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:

    N * queryInterval >= 30

Where N is the number of queries to get somewhere over 30 days.

So Irtp is waiting an extra queryInterval to account for this

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?

> 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.

Wes Hardaker