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
- [DNSOP] requesting WGLC for 5011-security-conside… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Paul Hoffman
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Matthijs Mekking
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Matthijs Mekking
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker