Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations

tjw ietf <> Fri, 03 November 2017 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6509913FF78 for <>; Fri, 3 Nov 2017 13:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bDv_hHI-na9a for <>; Fri, 3 Nov 2017 13:07:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4393613FF77 for <>; Fri, 3 Nov 2017 13:07:40 -0700 (PDT)
Received: by with SMTP id w105so3489547wrc.0 for <>; Fri, 03 Nov 2017 13:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QBVkKA6HwaKe9+YIai7SMSBCLrADaeUPciBcCcMAH48=; b=NpCP2MEe7P//LDwsAzZ4kHbaIzjseeHU1DeeIAPU3oapkAJ/qbizAm+6WjRB9lLVjA 4K0E9uS+qzO4902LrHMDukwl5CLcarrZMI8m4mpfhMLTI9EtJsWb4JT0DSz/Loh58u/4 SX2vUKtV2Z56qi78/jsSHWgz3NetJ2RnrwShxTSHIvMczuf9bedhdeNJNesZ00gj7K4X CFTNEp5Hvt/F82wSJT2UdR993e74zu3aS2LBQDoEWLo4/c1XR6K9Ol8WYB250t1+aBTP 0WNo6f9rh2CtmlUVH+hW3ruyHxmVNAvnTqwiOSoT/aX6zdXxBvniLiaKzak7UQnxJy00 CT3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=QBVkKA6HwaKe9+YIai7SMSBCLrADaeUPciBcCcMAH48=; b=p/DYwZtV7U4oUgdpBOutk0rQi+Kq42PAhCfET8axV/imw4ty+QIDMXOwgWWIUhKDRk S7AxAQrIHidolYzAGJNFDoC2RrMvs1BUuGyAmHXwTOdQeABwBlAMj4UVGYPRl+WxZEcC paHOZy9o+YSdnCWC/2fNCNDrJdP+pcANUkJU+LuVeACDaIzlS1/zXLSNiKjxDnolpaCi jWmERVvD5B/NTdPiPVQHrvkDBF1eEszRrHCU01PvlVJnS6sjop0pA0kh+V2buXgMuGT0 oNLPNIsGwCMRpguDK/5zp2HlgyrwUye/GoFkhathfQWD7D+7JzWQkx4LTHbTEHWUQ4VM XxxA==
X-Gm-Message-State: AMCzsaWTIxPpmR8MyMqQtv12UzK2V9fyhZXhFtNvRa1Pf6X6UTqfweiV RRKvQ+7PsQdbOpj9r0HjGl3ZCjzMyXKRngRWSOI=
X-Google-Smtp-Source: ABhQp+RQ9YwS2auXCyPFLmVJT25DB53cSkAW2YWmAaLkP+w2o1Y6F7mT+Nf1T/891xIFgUBULcDtySHRyVdE6Q0lcc4=
X-Received: by with SMTP id y97mr6716240wrb.165.1509739658679; Fri, 03 Nov 2017 13:07:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Nov 2017 13:07:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: tjw ietf <>
Date: Fri, 3 Nov 2017 16:07:38 -0400
Message-ID: <>
To: dnsop <>
Content-Type: multipart/alternative; boundary="f403045f4d1a0f1954055d19a832"
Archived-At: <>
Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Nov 2017 20:07:43 -0000


The Working Group Last Call has ended on this draft two days ago, with two
problems.   First, there was not enough comments from folks calling it
ready for publication, and second, there are two strong voices against
publishing this document.  With one against, we could work some rough
consensus, though the second  set of comments need to be addressed.

The authors are addressing the issues, and hopefully have a new version
before the meeting, and we can revisit this.


On Thu, Oct 26, 2017 at 1:42 PM, Michael StJohns <>

> On 10/26/2017 11:11 AM, Warren Kumari wrote:
> Wes and I do believe that this is an important document - getting
> these timers wrong potentially has really bad security implications;
> So, pretty please, review this document and send feedback. We've tried
> hard to make it readable, but the topic is unfortunately complex and
> can only be simplified so far - it is also really hard to talk about
> sliding windows of time.
> *sigh*
> It's really not complex and its neither a timer nor an interval nor a
> window - but a fixed point in time given the input data:
> earliest date when its safe to revoke ALL old trust anchor keys ::= latest
> expiration date of any RRSet containing the key(s) to be revoked +
> queryInterval (from 5011) + holdDownTime (from 5011) + queryInterval (from
> 5011)
> earliest date when the zone owner thinks its safe to revoke all the old
> keys ::= the above + safetyFactor
> The first query time is the maximum time it takes for all resolvers to
> make their first query (assuming no retries).  The second query time is the
> time for all resolvers to make the "next query after the hold down time
> expires" (again assuming no retries).
> The safety factor is there primarily to deal with network outages AT THE
> RESOLVER and is a SWAG that should represent a value that captures the
> answer to the question "given the retry interval and a 99% network uptime
> and N resolvers, how long until 99.99% of the resolvers have completed all
> necessary retries at both the beginning and the end of the process?"  Like
> most retry questions, this has a bi-modal answer - given a reliable
> network, the vast majority of resolvers will be successful in small
> multiples of the retry interval.   A very tiny few will not be successful
> even after 100s of retries.  The SWAG should pick a number of retries that
> balances the operational need to complete the process with the possibility
> of a few resolvers not getting the word.
> so:  safetyFactor ::= retryInterval (from 5011) * (5 + func(N))  - 5 is a
> SWAG to set a minimum for even a small group of resolvers.
> I was thinking Log2(N) - which would give 23 for 10 million resolvers or
> 28*retryInterval.   Or something suitably non-linear....
> Note that "latest expiration date of any RRSet containing the key(s) to be
> revoked" makes a worst case assumption:  that the pre-signed RRSets are not
> necessarily protected from disclosure.    If this is not true, then this
> reduces down to "the latest expiration date of any RRSet containing the
> keys to be revoked that has been seen publicly".  The document SHOULD
> assume that any signed RRSet may be available to an attacker whether it's
> been published in the DNS or not.
> 5011 was a timer based document because it applied to each resolver in
> each resolver's time domain.  When a timer fired on resolver A, it had no
> impact on the behavior of resolver B nor on the DNS server that was being
> queried.
> With this document, the 5011 timer intervals are useful only to figure out
> an earliest possible safe date given the previous live data set.  When
> that  (those) data set become irrelevant for the purposes of Wes' attack is
> pretty straight forward: when it expires!   The 5011 intervals can be used
> to calculate forward from that DATE and TIME to get an idea of when most
> well-behaving resolvers will have accepted new trust anchors even if they
> were being attacked.  Note "most".  There is no guarantee that even if you
> waited 6 years that all resolvers would get the new trust anchors and you
> just need to accept that the fall back is for the resolver owner to fix the
> problem when it occurs.
> This discussion has been helpful because it forced me to consider two
> things the root does that I never contemplated in 5011:  1) A steady state
> of a single trust anchor and 2) pre-signing RRSets.  Neither of these
> affects the resolver implementation, but both make the publishing/signing
> schedules more security sensitive - hence this document.
> Later, Mike
> _______________________________________________
> DNSOP mailing list