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

Michael StJohns <msj@nthpermutation.com> Wed, 19 July 2017 08:43 UTC

Return-Path: <msj@nthpermutation.com>
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 836E3131C3D for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 01:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 DxemkK2ek-eC for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 01:42:59 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CF7131C41 for <dnsop@ietf.org>; Wed, 19 Jul 2017 01:42:58 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id k71so2115514wrc.2 for <dnsop@ietf.org>; Wed, 19 Jul 2017 01:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=x0RvkLsUpv6wvqR+F8XLmxvA8DHLSUWsB89DNAGv6ow=; b=iEy/89i4AbmaNvwOCc17g1LJ6WDyakQJJ5SFGC6GOcvrPBFtXteX6v3swQ+YNxNBKH QDGFfacj93wQ9TW3NGjn7kMva0nsTFl16dgGOHBX6/mdUW7fnsVVyYKM6q1pTY6GwyfF 0PVbU9JcqnBCyKfnROCkuK1GVx+OtG7Z1A1DfTKybomT4CUg13fLBvsISoinBU+imtWY Z393yXaGAdCK+nj5XhMIR0vQ1SZ+j6iLfpPwc+M6QOBpi1CC2ESdwWe1MXhluEE6CbI6 aFgbn5LCBmyVodo3nCX992puSGx/8v9Bv1JuDyuL2ncN71Co2a71OtTv2iVf5pQazs3t IWJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=x0RvkLsUpv6wvqR+F8XLmxvA8DHLSUWsB89DNAGv6ow=; b=kmDRv6CLvaidMLk28n7oX4WnJUqMVFZK0DZ+3lXOKrK++xr/ayEr8nXJ+F7sGCx2pJ llnT1s9OGuHncYGqKuj7GHUq+MLq+WCMNeTMpjKx4RYrV6Ve3jFAmS76nOR3M8Q1u08/ LOKd6E5XVQeoACuIosQ2uJiS2kfbN0ivVrCUwuszuYSJabHytWCkIOU29Q+0MVhtwAaW qmbscEAnOZbizpfCTaTBv6US/ANOm+4klZCUM0KG45e/JtQ8QrJj2cm2VihzPe21jqzV 7I8OYEVUzEIuLjPLqVZ9/sUlCWmSNscv9GaZL5xlkHzFpyD+X2cCAVgFqwRFWrWIy8b1 rRtA==
X-Gm-Message-State: AIVw110Xs5MIg1u1NiEKgRwucgdG7d5AZMUd3iS0ZXlrYI85dWIBE4IV J07MRsvlZKXCOzQfKEY=
X-Received: by 10.223.128.177 with SMTP id 46mr3407626wrl.150.1500453776951; Wed, 19 Jul 2017 01:42:56 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:84df:4ec:c1b6:21a4? ([2001:67c:370:128:84df:4ec:c1b6:21a4]) by smtp.gmail.com with ESMTPSA id s2sm8144306wmb.27.2017.07.19.01.42.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 01:42:56 -0700 (PDT)
From: Michael StJohns <msj@nthpermutation.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: dnsop@ietf.org
References: <ybl4luqq05v.fsf@w7.hardakers.net> <CANeU+ZBzP+0REnZf0=_t60oXD_oA1nbYMRGcoFQ221buJb8YBw@mail.gmail.com> <ybly3s2le1m.fsf@w7.hardakers.net> <CANeU+ZD7NF07hZdsQT74bZar41dW6i2k6zaNvVnbRg0WYP4tMQ@mail.gmail.com> <yblmv8il906.fsf@w7.hardakers.net> <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> <ybl1sptlazr.fsf@w7.hardakers.net> <a1af5a54-8d50-698d-71e2-87f6dbeb9ca2@nthpermutation.com> <yblo9sxpfb8.fsf@wu.hardakers.net> <yblh8yhmucf.fsf@wu.hardakers.net> <77997330-f10c-22b3-4683-68e6d2a37cc0@nthpermutation.com>
Message-ID: <eef0317a-9be7-2eda-95b9-5fe716f8b981@nthpermutation.com>
Date: Wed, 19 Jul 2017 04:42:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <77997330-f10c-22b3-4683-68e6d2a37cc0@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JdYxph7wLn-k5N-ly9ukEIl1bYc>
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, 19 Jul 2017 08:43:01 -0000

On date time vs intervals - I finally realized why Wes and I are 
somewhat disconnected on this.

5011 was written as the protocol for the resolver and is totally 
interval driven.   (E.g. query and retry timers are set and fire based 
on when the resolver performs an action).

This document is being written for the zone publishers, and the process 
of publication is task driven and has humans as protocol element 
timers.  The actual publication of a DNSSEC RRSIG is divorced from both 
the date/time of creation and the RRSig's actual inception and 
expiration dates.  While there is a defined interval between inception 
and expiration, expiration occurs at a fixed point in time and that 
point in time is independent from the interval between publication and 
receipt by the client.

In other words - the correct (or at least better and less subject to 
being misunderstood) way of describing the various points in time the 
publisher should do something is by referencing the fixed point in time 
(expiration) where both publisher and client agree that something 
happens and then figuring other fixed points in time from that point.   
Or to restate it again - "A publisher must wait until June 5th 2010" 
will always evaluate to the same date and time regardless of who 
calculates it and when they calculate it; "A publisher must wait 30 
days" will not.


So :
"
publicationAddWaitInterval :: = MAX (30 Days, originalTTL of NEW DNSKEY 
RRSet) + MAX ( all calculated queryIntervals for OLD and new RRSets)  + 
addSlopInterval
queryInterval ::= MAX (1 hour, MIN (
                                                 15 days,
                                                .5 * expirationInterval 
DNSKey RRSet,
                                                .5 * originalTTL DNSKey 
RRSet)
                                           )

expirationInterval :: = expirationDate - inceptionDate
addSlopInterval ::= 2 * MAX(originalTTL of any  DNSKEY RRSet valid 
during the transition process)

The publicationAddWaitDateTime  is the date and time on which the 
publisher can assume that most of the 5011 capable resolvers have 
accomplished the addition of the new trust anchor to their trust anchor 
sets.  That date is the addHoldDownTimeInterval AFTER the latest in time 
signature expiration date of any RRSet without the new key.  This 
includes both published and unpublished RRSets. Publishers should 
refrain from creating or publishing DNSKEY RRSets signed exclusively by 
a new key until after this date. Specifically, the inception date of 
such an RRSig should be later than the publicationAddWaitDateTime"

The addHoldDownTimeInterval above differs from what is in 5.1 section 
2.4.1 in that this is the publishers view of when the new trust anchor 
is accepted by the resolver which may differ from a specific resolvers 
view (due to when things are actually sent and received).  Section 2.4.1 
has to be combined with the text in section 2.2 which states that the 
key isn't added until after the next time it is seen after the 
expiration of the add hold down. Also, the queryInterval term of this 
calculation should be the maximum of any DNSKEY RRSet seen during the 
transition - it's possible that the publisher may reduce the intervals 
or increase the intervals between RRSets and this provides the publisher 
with the worst case value that any given resolver should be using.


Let's not confuse resolver numbers with publisher numbers and spend a 
bit of time to get the language clear correct and implementable.

Mike