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

Michael StJohns <> Thu, 26 October 2017 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FE1013F421 for <>; Thu, 26 Oct 2017 10:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 WCqw5F4gsfV1 for <>; Thu, 26 Oct 2017 10:42:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F25213F3C7 for <>; Thu, 26 Oct 2017 10:42:46 -0700 (PDT)
Received: by with SMTP id n61so5318371qte.10 for <>; Thu, 26 Oct 2017 10:42:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=TwaKZXIvj4llNYaXKYzuTTrgXT2j5WfICVKuP2StuhQ=; b=aDYF8OBHcCCnO6SO9cMTaANNcN5tgZMS8ZrcU+xYEOnK1lo4fqnsSwDnD8CwVf/VjM k9HRNJwf0bn8LtnEbYmzEVP2LDytR//idGxB/Xq1EJvv4vfPTbLj1l+bCSIctZErtqv4 8sr4GSrZtNbtqLi+W97pVD0FINtGTxsRPWgV0tUrfjPYTLuTSGw1HunXGJm0qeJjWSJC 6qhsxzYttV1ZyvXGGiAXIxj1rNRx5rTdjaC6NfDVSfxDyuNuT3e4Vw5L0yqKDFjgBrkw +rkExW/4fMj8hVQYWo9gKCpiVnRMHRL8qBT5Gcy1SVXRqL+6sKphQCQKBmVciygDMApe /1KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=TwaKZXIvj4llNYaXKYzuTTrgXT2j5WfICVKuP2StuhQ=; b=C8dPWID4HoVd0TKikUNAzzQx3uRTfuyCf+OfU0Ttm5CX98nbV9CVl03/OgQ3kE2mCb Oa495QX29MOru0kSBI+dfIudsf5/htEieO9vwyKQsdkfB8AR9SSCu769ReRM7/QPbVBt jvx7H4oYooFY0hj7MsX/WFFeEE/6RXvP1y7othudbKVgOvtcbxqiTthYFnXUiwQaqs9H 1m+YW+pctHIdwER/f3UvQUa5BXwjTfD4ob0oWMRhKI3plb/7mIyEFuyjYPBVV+i9cDUo neO1tQ9u9min/X8uQLrR9UNmvzfJJpxNdl7dm8scHcZOkSTUPJQTUlGTMqAVKCy4L5VF AFPw==
X-Gm-Message-State: AMCzsaWQbHxWnSR7bYPl/M1YPIdtFb98dSn672HlbLn9ZSUw4/bJKQkX UfUw921kXmXqRobC7JLwppSyCDeZ
X-Google-Smtp-Source: ABhQp+Qgk3WI4NwW23rC50QKWA5dqZ2zxDETCbh+rHlyUVFtOYWNAVJMzipk+1Sfld6vI1jI20KtsA==
X-Received: by with SMTP id 26mr39354933qtu.51.1509039764925; Thu, 26 Oct 2017 10:42:44 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n131sm3606461qke.48.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 10:42:43 -0700 (PDT)
References: <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 26 Oct 2017 13:42:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------36F17CFEE38C48F92949D868"
Content-Language: en-US
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: Thu, 26 Oct 2017 17:42:48 -0000

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.


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