Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt
Michael StJohns <mstjohns@comcast.net> Wed, 24 May 2017 19:56 UTC
Return-Path: <mstjohns@comcast.net>
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 F31E7129B21 for <dnsop@ietfa.amsl.com>; Wed, 24 May 2017 12:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 lqwmBLL_-KW1 for <dnsop@ietfa.amsl.com>; Wed, 24 May 2017 12:56:58 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [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 ietfa.amsl.com (Postfix) with ESMTPS id 741CF129AA3 for <dnsop@ietf.org>; Wed, 24 May 2017 12:56:58 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-04v.sys.comcast.net with SMTP id DcNMdbzQtscBPDcOvdNBXN; Wed, 24 May 2017 19:56:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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 resomta-ch2-17v.sys.comcast.net with SMTP id DcOudCu5pbkqIDcOvdx1V5; Wed, 24 May 2017 19:56:57 +0000
To: "dnsop@ietf.org" <dnsop@ietf.org>
References: <149560445570.28419.14767177653896917226@ietfa.amsl.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net>
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: <149560445570.28419.14767177653896917226@ietfa.amsl.com>
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: <https://mailarchive.ietf.org/arch/msg/dnsop/BfzdOxkjFOWuzbhIHgSIw26iIXA>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt
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: Wed, 24 May 2017 19:57:00 -0000
I did a quick review - it's improving, but still is getting the basics wrong. 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" throughout). 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. Mike On 5/24/2017 1:40 AM, internet-drafts@ietf.org 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 >
- [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-secu… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Michael StJohns
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Wes Hardaker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Paul Hoffman
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Bob Harold
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Michael StJohns
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Wes Hardaker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Mark Andrews
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-… Michael StJohns
- Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnso… Edward Lewis
- Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnso… Edward Lewis
- Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnso… Andrew Sullivan
- Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnso… Mark Andrews