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

Michael StJohns <msj@nthpermutation.com> Mon, 11 September 2017 16:49 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 0CC96132644 for <dnsop@ietfa.amsl.com>; Mon, 11 Sep 2017 09:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 8JsQbM6s6ZRA for <dnsop@ietfa.amsl.com>; Mon, 11 Sep 2017 09:49:30 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 6A610132EBA for <dnsop@ietf.org>; Mon, 11 Sep 2017 09:49:30 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id r141so19800599qke.2 for <dnsop@ietf.org>; Mon, 11 Sep 2017 09:49:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=l9cbTcVbXvFpKDU4eTmPbetbYfpisUwide3yYHJz++U=; b=PT5KSr4dLs/w6J6hqB+OxyEaunhFiZ5ld2RitF5TInx2iF3EUUyvifnPm5vg1GZsMX niDjblJgpPPZvnlf1TP7nKWYXiDanRElIBqEkuJTW8zVhe4A9I9sPORp4crL65oLb80s sA8VoXFch81ogMtP04xltOd/vVbq6QvbnuM8tVpIBHqAk857+PfADRi+mLGdlxtglttH 1UQu90qPR+NuMiszoBEiBFxt1rXdzRNudo2dqQw8RXDUVZLKsVWFL4Dj9RN94hNXXPSO yagIS+l5Rkp+kSkeGdvAJavMxtj5TIbqbxE1T1+RXMuSFQ+It7SDEil1vvnMj/R4RFrN iDMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=l9cbTcVbXvFpKDU4eTmPbetbYfpisUwide3yYHJz++U=; b=IHNsemYpe62FD2XMvoN0v1teMVHI1pGj9ZQuEcMz0woNDZCKP0JTmhRZoR2zlOdN60 iewGz7PBvCY1jM2I4Ux1MCk/HiXeTQyhUgO+p04UkzjxtN9LgxooVUQ/R6Q2w2Pe/w6n 9ltj3dG1+el5KsZxePzxW1KmXogu6TpOkHu3NcklAAOQJrC68D3E8dSqhM0LOaDBrozH OPmRue0W2wY2dxOXvgx06WZojPBO1gsXQ4AAVZEfKDQfvrVDcrPbA6CMHFSzExIK6UhF dKmeSBfUbefpzdiAeWDXMh4AzvmwY/JHJaQQ/W8Q9j485AT9rvhRJt0vdPgSV6Es02BZ qiJw==
X-Gm-Message-State: AHPjjUhuZXIb8jZ99UIiPEgrdiTLE0O/WNeHNSB6mIkC8dqYu+R0DFlg WTpvfDp1nS19hRfJptI=
X-Google-Smtp-Source: AOwi7QBTa6yDd0Ifxo7oVdy4+Jn8IdM0NQ2e7pLrndeoPqFsgMOCnOCsIa22O9mcYLF1xb/+FwWDDg==
X-Received: by 10.55.174.65 with SMTP id x62mr16663936qke.200.1505148568988; Mon, 11 Sep 2017 09:49:28 -0700 (PDT)
Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id t56sm6719358qte.54.2017.09.11.09.49.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 09:49:27 -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> <eef0317a-9be7-2eda-95b9-5fe716f8b981@nthpermutation.com>
Message-ID: <8e4ed0fd-9732-ccee-9119-05be00c97d9f@nthpermutation.com>
Date: Mon, 11 Sep 2017 12:49:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <eef0317a-9be7-2eda-95b9-5fe716f8b981@nthpermutation.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/54uLuvgdkEoskUhVSlmWalwcngc>
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 16:49:33 -0000

Wes/Warren - you still owe a response on the following.



On 7/19/2017 4:42 AM, Michael StJohns wrote:
> 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
>
>
>
>
>