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