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

Matthijs Mekking <matthijs@pletterpet.nl> Mon, 11 September 2017 11:59 UTC

Return-Path: <matthijs@pletterpet.nl>
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 0976013232C for <dnsop@ietfa.amsl.com>; Mon, 11 Sep 2017 04:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18_cTO-3JtUF for <dnsop@ietfa.amsl.com>; Mon, 11 Sep 2017 04:59:43 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [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 ietfa.amsl.com (Postfix) with ESMTPS id 1D74D132D22 for <dnsop@ietf.org>; 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 dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 1BDB7BA9C for <dnsop@ietf.org>; Mon, 11 Sep 2017 13:59:41 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: dnsop@ietf.org
References: <ybl4luqq05v.fsf@w7.hardakers.net> <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl> <yblvakvn76v.fsf@w7.hardakers.net>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <b799e983-43d8-b6db-7a13-40c5cdf37800@pletterpet.nl>
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: <yblvakvn76v.fsf@w7.hardakers.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1NZ6_psbfxxL_ukYj2QPDqe1Xkc>
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: Mon, 11 Sep 2017 11:59:45 -0000

Wes,

On 06-09-17 18:05, Wes Hardaker wrote:
> 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:

But it is:

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

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,
RRSigExpirationInterval))

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


> 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,
  Matthijs



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