Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

Michael StJohns <> Fri, 26 May 2017 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EE5712009C for <>; Thu, 25 May 2017 20:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 7kxprn0RLtax for <>; Thu, 25 May 2017 20:27:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD1D0126579 for <>; Thu, 25 May 2017 20:27:14 -0700 (PDT)
Received: by with SMTP id u75so190495559qka.3 for <>; Thu, 25 May 2017 20:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QAbBYVQzm/R4Rcxp3p4ANZvxkNv9k05TogXuOwoP1lY=; b=BWc9DWkul2lPfdRHWIkgRU3AqIHUgu+yPAar1cMq12j7FX1l0tYrBP7qLJRnlqljF4 Fkzas3hPkXPVFblDKL6eWh1L09kaJzGbPtTI3hEQXmYONVxO+qygGRbuP/bbAlA9yCd9 T2lCmIJ9NpnkMhXwi7GtUvn/PcyAD/D2r5mZOGd/DX2HM4Qp5VYZrilIUfR7Uv75RNSB miAzh0lp3gdQFm5cyVyyJEdCNvebowfzW1xXWyoNBMdLdZ++dx9vfLv1shMNyoqeqWgF a8epUKq8GfWE6kqnNAfxyfjM9L9ILBpxWXfxngMXVLwQ9s+3GM5RSGCnqHPS3tWuaSGk YprQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QAbBYVQzm/R4Rcxp3p4ANZvxkNv9k05TogXuOwoP1lY=; b=sVhBisBQ3XstjvKT15Uw6lU5hCBX/6XDab7RICCMKd2RYBKH1I4Tz+nwO1rfFCAgQD 2HG1IEks5FDNhVwfukl5sqsYK1i1kMVU0HoXrXacC9GU6DlPcU2c4ICGiCwBAjjtnypb tRA6ykBZNs5SS4TDNNSIw6Q9aK1KPO88pj20IVHDez3WfApU6FdSTtrabysv5UnHxa6T hIC7yuKVF1lqc0CQO6j9209tC1ZiadqtRmLZ04iuOerI3e59OZbuEf+f3f4bjrl5qtN7 SpgAQFmMi8aDxQLCmNk49B3NiB5h5vtYGaLF7BC5bgk9ymXgcyMMiWEMjKx8ZR1HooQe a0Ig==
X-Gm-Message-State: AODbwcCUYheQXCZs0wvBareqtPVy2xwk5n5Uw87ZzIY3BcIjl6bQADTj W05n8sOy0CCzefTU
X-Received: by with SMTP id z7mr41494881qkc.121.1495769233793; Thu, 25 May 2017 20:27:13 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:a2e0::1077? ([2601:152:4400:a2e0::1077]) by with ESMTPSA id r22sm6055459qke.25.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 20:27:12 -0700 (PDT)
To: Mark Andrews <>
References: <> <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 25 May 2017 23:27:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt
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, 26 May 2017 03:27:17 -0000

I appreciate your comments, but they are pretty much inapplicable to the 
document.  I'd suggest if this approach is important to you that you 
draft an ID and gather comments on that document.

If you want to recommend changes to 5011 - same comment.

What we're discussing now is guidance for the publisher that's trying to 
understand the implications of following 5011 timing considerations and 
how those relate to the publishing schedule.


On 5/25/2017 9:52 PM, Mark Andrews wrote:
> These questions are why I don't like RFC5011.  There is lots of
> missing metadata about DNSKEYs that exists in CERTs.  We could
> supply this metadata in TBD records at the apex of the zone which
> are like extended DS records (I will call these records VU records).
> Things like "valid until" where validators go insecure if they no
> longer have any stored trust anchors with a "valid until" in the
> future.  Where zone operators commit to signing with the DNSKEY
> until after the "valid until" time has passed.
> e.g.
> 	. VU <date> <key-alg> <hash-alg> <hash>
> where these records get updated periodically if you want to extend
> the life of the matching DNSKEY record.
> A KSK key rollover would involve publishing a new VU record along
> with the new DNSKEY record.
> 	. VU <date1> <key-alg> <hash-alg> <hash1>
> 	. VU <date2> <key-alg> <hash-alg> <hash2>
> If a validator is off line during the KSK rollover then it would
> continue to have just
> 	. VU <date1> <key-alg> <hash-alg> <hash1>
> and if it is restarted after <date1> it would start in insecure
> mode.
> Similarly if it just misses a updates of the VU records to extend
> the DNSKEY's lifetime it would start up insecurely.
> 	. VU <date1> <key-alg> <hash-alg> <hash1>
> 		to
> 	. VU <date2> <key-alg> <hash-alg> <hash1>
> Mark
> In message <>, Michael StJohns writes:
>> Hi Paul -
>> I appreciate that both you and Wes have new skills related to mind
>> reading about my intents, but you're probably reading the wrong mind.
>> I have stated the question a publisher needed to answer fairly
>> succinctly in the past:
>> "How long must a publisher wait until it is reasonably certain that a
>> new key has been installed as a trust anchor in all but a slim minority
>> of live DNS 5011 resolvers?"
>> That question is the correct one to answer because it covers all the rest:
>> "How long should a publisher wait after publishing a new key before it
>> signs the trust point DNSKEY RRSet with ONLY that key?"   Same answer as
>> to the question above because you have to wait to stop signing with all
>> the other trust anchors until the trust anchor uptake rate for the new
>> key at the resolvers is sufficient (for some value of sufficient).
>> "How long should a publisher wait after publishing a new key before it
>> revokes ALL of the old trust anchor keys?"   Same answer to the above,
>> and incidentally forces you to only sign with the new key.
>> Note that the answers to the question the document asks are different
>> than as stated (because of the one in/one out assumption):
>> "How long must a publisher wait after publishing a new key before it
>> signs the trust point DNSKEY RRSet with that key?"  Answer is that it
>> may begin signing the RRSet immediately upon publication, resolvers will
>> not start tracing trust through that key until at least the hold down
>> time.  The publisher may indeed delay signing as long as it wants as
>> long as there are other trust anchor keys available.
>> "How long must a publisher wait after a publishing a new key before it
>> revokes an older trust anchor key?"  Answer is that it depends on how
>> many trust anchor keys are assumed to be in most resolver's set.  If
>> only one, then you wait until you are "reasonably certain that a new key
>> has been installed as a trust anchor..."  If its more than one, then it
>> depends on the trust point's policy of how many keys to keep more than
>> anything.
>> The important part in this document is getting a handle on the
>> publication uptake time for most resolvers given a new key.   The rest
>> of the guidance flows from that.
>> My specific point is that this document should talk to the protocol, not
>> limit the discussion to current practices - especially since current
>> practices are really a proper subset of the allowed behavior.   I do
>> understand what the root is doing right now, and you're both correct
>> that I wish they were using at least a two key trust anchor set as
>> steady state.  But that still doesn't obviate my point about writing the
>> document to the protocol and not the practice.
>> In the current document, I'd rewrite the math and discussion to deal
>> with how I framed the question (e.g. its about how long it takes to
>> populate enough resolvers).   If there is then a desire to talk about
>> the current root update process, then do that as an appendix or an
>> example and I think doing the analysis against the current root key
>> update process is a good idea.
>> Later, Mike
>> On 5/25/2017 1:15 PM, Paul Hoffman wrote:
>>> Most people reading an RFC about the DNS probably expect it to be
>>> about the public DNS we know. That public DNS currently has one KSK,
>>> and there are no plans to change that (although there might be in the
>>> future). Given that, and given Mike's comments on the doc, I propose
>>> the following.
>>> Change the Abstract from:
>>>     This document describes the math behind the minimum time-length that
>>>     a DNS zone publisher must wait before using a new DNSKEY to sign
>>>     records when supporting the RFC5011 rollover strategies.
>>> To:
>>>     This document describes the math behind the minimum time-length that
>>>     a DNS zone publisher must wait before using a new DNSKEY to sign
>>>     records when supporting the RFC5011 rollover strategies in zones
>>>     that have a single key signing key.
>>> Just before Section 1.1, add a paragraph:
>>> This document describes only the case where a zone has only a single
>>> key signing key (KSK). It does not apply to zones that have multiple
>>> KSKs. The current public DNS has a single KSK covering the root zone,
>>> and this document focuses mostly on that KSK in its discussion.
>>> --Paul Hoffman
>>> _______________________________________________
>>> DNSOP mailing list
>> _______________________________________________
>> DNSOP mailing list