Re: [DNSOP] new dnsop related draft: RFC5011 security considerations
Michael StJohns <msj@nthpermutation.com> Wed, 03 August 2016 18:10 UTC
Return-Path: <msj@nthpermutation.com>
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 BA9E212D678 for <dnsop@ietfa.amsl.com>; Wed, 3 Aug 2016 11:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 zITssY5hOuAg for <dnsop@ietfa.amsl.com>; Wed, 3 Aug 2016 11:10:12 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9951612D12E for <dnsop@ietf.org>; Wed, 3 Aug 2016 11:10:12 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id x185so17536116qkc.2 for <dnsop@ietf.org>; Wed, 03 Aug 2016 11:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mtewOVxFT4sj6e0Ap0pRVgVj2jHvC46iWJmmXM26Rd0=; b=ahMH4Pll34ZWS16UIWycAA7DMShRuQdWxEy8brAZ78l+U+o5GIkhr9YltzraFVeLEJ +kgaOGGl8fXbXQkDSmwHXQHgmeoki23FeESp01GAleWfjgbO3Y1OrDlXDLSNsGBnt7KI Mybv4+ygvZalHJWRXns3mP/OMYlhZbjs8Wo+7iRQGjvcLmie+JaL08vU5qkUBwqoYP4/ Eq/1exP4qWy9VLMKdQ2tDSmrzgDXWqKIO/LjpVRggFqPrBGBNCzChZMBZZ8hfeVe7U8V wUEDTSxlioB2AryMkuQt46glwz9BWyKANhwZ+3Lk8URKRqUBvjzv5Kt+6S3jrULk+8// sdZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mtewOVxFT4sj6e0Ap0pRVgVj2jHvC46iWJmmXM26Rd0=; b=ltdoqyoYt8BytqvR2V/9i0/p9w4um5nkLyYgUrdQDdFMtctBWohhR9GrF0+L34Z34r TN03DolctwJ+rtIUPDSUe7fcVt8LXpJQkupucibHEB6N9VJoQbzmLHpdRsj8PvAY5Gtk ZK5M/LNVWy6nz9NQbwNhGvXJvfcO9DpkuXuzdKT3jGxJFWTVGOPTf4OvdGCgjOsr00D7 yQXy2J9xL6tTfIxVpahjlchJeL0+Cm1Q1Kjsyluwz8f7uugRwxpCrKq18qnxLdn61s0J QpDLCvn3wDcVCbsKZUa0SwI6f8NjiEN78p/rwLeO463NKo+O7W7tsNoqhi1ThXncDj+1 rK9A==
X-Gm-Message-State: AEkoousqqrluTUCSsjCPTh146Bgr83FTJBsxme/jGkzkfc7brpKifDhGWJuA9IkaieTyDA==
X-Received: by 10.55.134.3 with SMTP id i3mr1476515qkd.50.1470247811209; Wed, 03 Aug 2016 11:10:11 -0700 (PDT)
Received: from ?IPv6:2601:148:c000:1951:7de1:554d:e4ff:ff45? ([2601:148:c000:1951:7de1:554d:e4ff:ff45]) by smtp.gmail.com with ESMTPSA id 55sm4772053qtm.36.2016.08.03.11.10.09 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 11:10:09 -0700 (PDT)
To: dnsop@ietf.org
References: <0lfuqoqhd7.fsf@wjh.hardakers.net>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <9208eb19-1d92-fdab-0c9a-f8b80b2c7c36@nthpermutation.com>
Date: Wed, 03 Aug 2016 14:10:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <0lfuqoqhd7.fsf@wjh.hardakers.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zwQzkM3-EHjSY8ufOdSXm8wJtwA>
Subject: Re: [DNSOP] new dnsop related draft: RFC5011 security considerations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Aug 2016 18:10:15 -0000
On 8/1/2016 6:00 PM, Wes Hardaker wrote: > The following draft, authored by Warren and I, might be of interest to > the dnsop crowd: > > https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-00 > > [it currently does not have a home] I went off and thought about this for a while and came up with: 1) The absolute earliest time that the FIRST resolver would install a new trust anchor: publicationTime + holdDownTime 2) The absolute earliest time that the PUBLISHER can assume that the FIRST resolver has installed the new trust anchor: (latestExpirationTime of all DNSKey RRSets that do not contain KNew or publicationTime (whichever is later) ) + holdDownTime 3) The time when a publisher can assume reasonable numbers of resolvers have installed the new trust anchor (and incidentally the period in which they should avoid revoking the keys being used to add the new trust anchor): Some time after (2) depending on how much penetration you want and making wild guesses about things like off-line resolvers rejoining the internet after being away. So I think this is related specifically to the original TTL. So maybe this is latestExpiration + holdDownTime + N*MAX(any originalTTL published in the DNSKEY RRSig record over the new key) where N is >= 2. But this is no better than a SWAG at the numbers. For the current root key rollover stuff, I think 3 months is a pretty good SWAG. The above doesn't actually change the basic model of DNS as an incoherent data protocol. The time from publication to acceptance by an individual client of any published data varies drastically from the acceptance of that same data by a different client at a different place in the network with different query patterns. If a new NS record were added to the root tomorrow, we wouldn't expect the entire world to pick that up immediately and we would expect that there would be some time until a large percentage of resolvers would know about the new NS and start using it. That incoherence time would be related to the time it takes to propagate the NS records to the other root servers and for TTLs to expire on the existing data and the actual liveness of the resolvers. Why this calculation should be very different for the root DNSKEY RRSet escapes me. Mike
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Shane Kerr
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Matthijs Mekking
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Warren Kumari
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Michael StJohns
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Matthijs Mekking
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Matthijs Mekking
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wes Hardaker
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Bob Harold
- Re: [DNSOP] new dnsop related draft: RFC5011 secu… Wessels, Duane
- [DNSOP] new dnsop related draft: RFC5011 security… Wes Hardaker