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

Wes Hardaker <wjhns1@hardakers.net> Wed, 06 September 2017 16:05 UTC

Return-Path: <wjhns1@hardakers.net>
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 88178132031 for <dnsop@ietfa.amsl.com>; Wed, 6 Sep 2017 09:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF9cqze03DX9 for <dnsop@ietfa.amsl.com>; Wed, 6 Sep 2017 09:05:44 -0700 (PDT)
Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BB6124207 for <dnsop@ietf.org>; Wed, 6 Sep 2017 09:05:44 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 5B65A20C02; Wed, 6 Sep 2017 09:05:44 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop@ietf.org
References: <ybl4luqq05v.fsf@w7.hardakers.net> <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl>
Date: Wed, 06 Sep 2017 09:05:44 -0700
In-Reply-To: <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl> (Matthijs Mekking's message of "Thu, 20 Jul 2017 14:34:56 +0200")
Message-ID: <yblvakvn76v.fsf@w7.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/npAuDmqk1lesq7b5o7QFcSnnKi4>
Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 06 Sep 2017 16:05:45 -0000

Matthijs Mekking <matthijs@pletterpet.nl>; 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
possibility.

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
USC/ISI