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

Michael StJohns <> Wed, 24 May 2017 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F31E7129B21 for <>; Wed, 24 May 2017 12:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 lqwmBLL_-KW1 for <>; Wed, 24 May 2017 12:56:58 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 741CF129AA3 for <>; Wed, 24 May 2017 12:56:58 -0700 (PDT)
Received: from ([]) by with SMTP id DcNMdbzQtscBPDcOvdNBXN; Wed, 24 May 2017 19:56:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20161114; t=1495655817; bh=RE9MJucRqLpRVlrFq/BFaLT/eLX3yOcqWlf2YcOUgIo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=HGuLuzbDQY25mBNv5MUfvJcl8pcZ7YJh3cCe28PqhPWCWzJzDgprhx1GxrVyclVvx R6yWrQj17qycdZXwkLFJm6TgT4bggMlb21gcRfXlmPc9mjH8eAFgRgOLErXxvFF4DU cuKqvglulAuQ7G2TnalSkPIg0wRz+ehLspyJQJ4yBFYr4CTgFAQ/s60/xXN+ZSTO6u SASaUmDOUNAVVra76xeWdrCYUTDx6cuec/eqJH2iEtjuBfUp0Xd7uwiF9oNHuX/bCp Vxwj6+By3WHehnPG1sF2U9sM7HnZTAO54QVbnNxs9IzVVaNh7PRITUAlGRyC3B6l+/ aTyQr4T77SxLQ==
Received: from [IPv6:2601:152:4400:a2e0::106f] ([IPv6:2601:152:4400:a2e0::106f]) by with SMTP id DcOudCu5pbkqIDcOvdx1V5; Wed, 24 May 2017 19:56:57 +0000
To: "" <>
References: <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 24 May 2017 15:56:56 -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
X-CMAE-Envelope: MS4wfEKuaij9SjBlvDKO9hT1ywHOMyQejZg2pIQdm3NIGfm7VqPEagsheOSK2pCA0sjGr/rNmObEOWtfkBdGdQRFSF1CMbjdG4XIg9+naIZDhei2nPtZ5cnk euDtx6DPqXYbOvCWpQtwb35lLVguDosTbFYPyB6gmnGRhfjgPr9C0iig
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: Wed, 24 May 2017 19:57:00 -0000

I did a quick review - it's improving, but still is getting the basics 

This document is written with language that works only with the start 
with one key/one key in/one key out/end with one key model for trust 
anchor keys.  5011 specifically recommends that there be at least two 
trust anchor keys and this document doesn't quite get the problem 
statement right given that both 5011 and DNSSEC support a steady state 
of more than one trust anchor key.

The actual issues related to the problem stated (of publisher guidance) 
are "How long must a publisher wait after publishing a new key before 
revoking ALL previous trust anchors?" And  "How long to wait before 
signing ONLY with the newest key?"  (These are actually the same 
question looked at from slightly different angles). The issue is not the 
more limited generic question of how long to wait before you start 
signing with the new key.  (Please avoid the phrasing "use the key" 

For example, consider a trust point with trust anchor keys A, B and 
where A is generally signing the DNSKEY RR Set at the trust point.  The 
publisher desires to replace A with a new key C.   The publisher 
generates C, signs the RRSet with B and publishes the RRSet containing B 
and C.   At time T+holddown, C has probably joined the first of many 
validator trust point sets.  At some time T+holddown+N, most of the live 
validators will have added C.   At this point the publisher revokes A, 
publishes a trust set with A, B, C and signed with A and B and continues 
this for at least the hold down time.  At which point the published 
RRSet is now B, C signed by B (C is a standby key) and most validators 
trust points have B,C installed in them.  (Or B signed by B for that 
matter - "Missing" is an abnormal state, not an illegal one and was 
there mainly because  RRSet size issues  mostly weren't brought up while 
5011 was being discussed).

Note that A could have been revoked starting with the first publication 
of C  at the cost of reducing the validator trust anchor set to a single 
key.  That would be the model for an emergency revocation of A.

So:  Minimum time to start signing with the new key is the hold down 
time (you can sign earlier, but no validator will trace trust through it 
so why bother?).
Minimum time to wait before revoking all previous trust anchors OR 
signing the RRSet ONLY with the new key is hold down time counted from 
expiration date of the signature over previous DNSKey RRSET plus some 
slop - in the example the slop is 7 days and that's a reasonable value 
for the parameters.   That's also the minimum time a new key should be 
published and signed even if you're planning on using it as a backup key 
and not including it in further RRSets for now.

Note that the example in the draft at section 6 is missing a 
consideration.  It's not the expiration time, but the expiration date 
that needs to be considered - if you issue a new RRSet while the 
signature on the old one has only 4 days to go, you have the 4 day 
exposure, not 10.


On 5/24/2017 1:40 AM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>          Title           : Security Considerations for RFC5011 Publishers
>          Authors         : Wes Hardaker
>                            Warren Kumari
> 	Filename        : draft-ietf-dnsop-rfc5011-security-considerations-01.txt
> 	Pages           : 12
> 	Date            : 2017-05-23