Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

Bob Harold <rharolde@umich.edu> Tue, 07 July 2015 18:12 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61DE1A0196 for <dnsop@ietfa.amsl.com>; Tue, 7 Jul 2015 11:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.578
X-Spam-Level:
X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 sxbxn1JjSAgB for <dnsop@ietfa.amsl.com>; Tue, 7 Jul 2015 11:12:39 -0700 (PDT)
Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (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 818A81A0140 for <dnsop@ietf.org>; Tue, 7 Jul 2015 11:12:39 -0700 (PDT)
Received: by ykfs198 with SMTP id s198so80680500ykf.2 for <dnsop@ietf.org>; Tue, 07 Jul 2015 11:12:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pp4AuY9xLUQTYE2yb0f5sG/NdNMPS3jv7EjdYkB77OY=; b=e9Y5O6Y29ZPIq8Sa6O8/u5WUsdsXjZXm43UTCrauH6q07BCF0XjYhhPX7LozPk7v1R klDp3nlPSsAdb+iSeIRPwzWV0oP3zNU1TXGMRv1Ua+iEROlX00NqRzhHtgpXoHaX4eNr J9fUceot2ja8f1XqJ7LrzSYs3uoySTyd8bhQF/x01eJJC8OUUnKpu4ltOGO+poWWdNJ3 ZIxZ1SP2TYPDTrfNVvlBunZyQKAxjTRLjn9P6h1YBgZP8c3JaYqkZbZ5idegIeZ1qeD0 1QTREQkwHx84MraqP2S6VB9kAI5hI1XtMbawFT/9l0hkL1g9Y+7bOvPp6VSFN/90Up0Q uHPw==
X-Gm-Message-State: ALoCoQlc6uX3rfJAdh/N5WJZ856yE3om+B8+3dompaPbxoVIhYw1oVlSiitW1P7ZafCYqHzogyZp
MIME-Version: 1.0
X-Received: by 10.129.4.17 with SMTP id 17mr6722310ywe.36.1436292757411; Tue, 07 Jul 2015 11:12:37 -0700 (PDT)
Received: by 10.129.52.194 with HTTP; Tue, 7 Jul 2015 11:12:37 -0700 (PDT)
In-Reply-To: <C1599C26-20AF-48F9-9E99-BB8F53477481@karoshi.com>
References: <CAHw9_iKmhA+f8QyuLkWeXQDfwprydVaGkR+LVJACGtsTB0+Pfw@mail.gmail.com> <FBEB0A0C-C749-4B40-AA63-271E6B073A4B@fl1ger.de> <73D482C3-01FD-4309-AF1C-A6226D1D40F9@karoshi.com> <E8F87D3D-9C50-4974-8D1E-A04061B8270A@virtualized.org> <C1599C26-20AF-48F9-9E99-BB8F53477481@karoshi.com>
Date: Tue, 07 Jul 2015 14:12:37 -0400
Message-ID: <CA+nkc8BKTQOfK8go0kVv3oE4QzDqmm37uCQJU5E6bbLmXWqmYA@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f60f8998cbd051a4cf7c7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/1c6wLHyTUBn94URLX8XWd6x4Bvs>
Subject: Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 07 Jul 2015 18:12:42 -0000

On Mon, Jun 29, 2015 at 8:03 PM, manning <bmanning@karoshi.com> wrote:

> Why, yes, I still do.  (and it can be found in the IEtF archives)
> https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01
>
> As to why,  perhaps I am missing the obvious, but if SUDSTA proceeds, does
> it matter if the origin IP of the root zone being served
> is sporadically distributed?   It seems that one could not presume to have
> the data to assert the penetration of the new keys nor the
> origin of the stale keys, if that information was diffused through the IP
> address space.
>
>
> manning
> bmanning@karoshi.com
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
>
>
>
> On 29June2015Monday, at 16:28, David Conrad <drc@virtualized.org> wrote:
>
> > Bill,
> >
> >> This looks very much like the draft that Olaf, Johan, and I wrote at
> the same time MSJ was proposing what we have now.
> >> You might want to talk to either Olaf or Johan for more details.
> >
> > Don't suppose anyone has a copy of that draft?
> >
> >> And yes, this will fail if any of the loopback drafts are deployed.
> >
> > Sorry, I must be missing something obvious. Why?
> >
> > Regards,
> > -drc
> >
>
> Either method seems usable, but we really need one of them deployed

Local root on loopback - if they update the root zone regularly, it should
just work, right?  If they don't update, they will keep validating with the
old root keys - will the next level break as soon as the old root key is
gone, or only when a subzone rolls their key based on the new root key?

-- 
Bob Harold