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

Wes Hardaker <wjhns1@hardakers.net> Tue, 12 September 2017 23:41 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 BCD5F1343AE for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 16:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no 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 efBFTo5IZjYf for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 16:41:24 -0700 (PDT)
Received: from mail.hardakers.net (unknown [168.150.236.43]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E891343AD for <dnsop@ietf.org>; Tue, 12 Sep 2017 16:41:23 -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 68C38243F8; Tue, 12 Sep 2017 16:41:23 -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> <yblvakvn76v.fsf@w7.hardakers.net> <b799e983-43d8-b6db-7a13-40c5cdf37800@pletterpet.nl>
Date: Tue, 12 Sep 2017 16:41:23 -0700
In-Reply-To: <b799e983-43d8-b6db-7a13-40c5cdf37800@pletterpet.nl> (Matthijs Mekking's message of "Mon, 11 Sep 2017 13:59:40 +0200")
Message-ID: <yblwp53qycc.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/JOJGv2rjzT3QrVyyHe4UHl0VgYM>
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: Tue, 12 Sep 2017 23:41:25 -0000

Matthijs Mekking <matthijs@pletterpet.nl>; writes:

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

In the end, the first (newly valid) time the validator queries for and
gets the new dnskey will be N minutes after the signature expiration
time.  The validators timer will start at that point.  Because
queryInterval is always equal to or less than 15 days, the validator
will always see the key twice before the 30 day window is up.  So if 30
days is a multiple of the query Interval (eg, 15 days, or 5 days) then
the first time the validator will see the key after the 30 day window is
N minutes after the expiration time plus 30 days.  Thus only 1 query
interval needs to be added in this ideal case.

The less than ideal case is when 30 isn't evenly divisible by the
queryInterval (eg, 7 days).  At which point the first time the validator
will see the new key after the (sig_exp + N + 30 days) mark will be at
(sig_exp + N + 30 days + remainder(30 days / 7)).  So we don't need to
add in a full queryInterval to cover the offset and can calculate it
instead.

(that being said, I put "you might pick 2x for simplicity" into the draft)
-- 
Wes Hardaker
USC/ISI