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

Michael StJohns <msj@nthpermutation.com> Thu, 25 May 2017 19:22 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 9344D128DE5 for <dnsop@ietfa.amsl.com>; Thu, 25 May 2017 12:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 At0KMmZAGsJX for <dnsop@ietfa.amsl.com>; Thu, 25 May 2017 12:22:14 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 9EDFB127876 for <dnsop@ietf.org>; Thu, 25 May 2017 12:22:14 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id v27so188532839qtg.2 for <dnsop@ietf.org>; Thu, 25 May 2017 12:22:14 -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:content-language; bh=yvrNJgU4LykrAI96774F2uhcKBavG1+40N58zTlnYiU=; b=tlGWBnX7J7zpuwtNWwPJZYxcYnb2a6uCRysBpRc5TxOJOitUuEjrPBTQkgOD2wGJKO F09L+8I1GOcq8P+VRumxyKmu+TTjt+9sgP05MalSUXOl396bbmh5JaNnyaUXIaEjZe2D d6TfZ4PJ95Tet+ePDJDxMe8dorV7P/SoNbjq/5rpoYBI9GKQAewOz4uvmj+uQ4/44wOn +4zIgmvevUGnOZD4ym4qmpkjmLofrjDP4EMfRxqPBhlmf+D1cd5Idv8s7rjKgtS9kQgH frMb2uK+OqKCelMM+tkMHI/D2jk94eWTrRzd9QYxGFBGxXoeZH3Wot/1YzqQHvm3utbC s7Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yvrNJgU4LykrAI96774F2uhcKBavG1+40N58zTlnYiU=; b=ROYByDz4KkJ+951yZdTM3CXpqlkZD98CJ6xjHPDO/CXN9YW3SkQD4ofdi5cshB+1RR j2p7R3dzjmBbfGfwOGYcPEQ1f5jW729WBLQFectc9mAQ/E9xckwB1SrKbXqzUJ4hk6D9 zLmdlqkM6p0MlLel6SDoaaC5UiQ0d9B8Jwbac6fDIcYHTAsjF8yI+Y3WFC5lMiSvSNvh SsyAy8TdroNvp/HcoBxCwhNzzbXJF2dEQv9+qizKOMRWt4cbVsoGiIdT7vdn9Xa4Tb5g 7nKQqqsrAFJGsfytqWzSGnzOe1kxTRl14mSWfNGkCdbjn/EPNh+MvGbhbk7PBcScSxM6 zZTw==
X-Gm-Message-State: AODbwcB3mCo4HYbf2mph9GzsWV3IC3yIrZZCWQub0aNknuczbtIRT5q0 P8bwVqUoQZITRr/m8Q4=
X-Received: by 10.200.52.165 with SMTP id w34mr44675378qtb.77.1495740133364; Thu, 25 May 2017 12:22:13 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:a2e0::1077? ([2601:152:4400:a2e0::1077]) by smtp.gmail.com with ESMTPSA id m7sm5231935qtm.10.2017.05.25.12.22.11 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 12:22:11 -0700 (PDT)
To: dnsop@ietf.org
References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <ybl60gq9bq2.fsf@wu.hardakers.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com>
Date: Thu, 25 May 2017 15:22:10 -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: <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6vB5uy287s27UyUbOuDW2Eltkzs>
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: Thu, 25 May 2017 19:22:17 -0000

Hi Paul -

I appreciate that both you and Wes have new skills related to mind 
reading about my intents, but you're probably reading the wrong mind.

I have stated the question a publisher needed to answer fairly 
succinctly in the past:

"How long must a publisher wait until it is reasonably certain that a 
new key has been installed as a trust anchor in all but a slim minority 
of live DNS 5011 resolvers?"

That question is the correct one to answer because it covers all the rest:

"How long should a publisher wait after publishing a new key before it 
signs the trust point DNSKEY RRSet with ONLY that key?"   Same answer as 
to the question above because you have to wait to stop signing with all 
the other trust anchors until the trust anchor uptake rate for the new 
key at the resolvers is sufficient (for some value of sufficient).
"How long should a publisher wait after publishing a new key before it 
revokes ALL of the old trust anchor keys?"   Same answer to the above, 
and incidentally forces you to only sign with the new key.

Note that the answers to the question the document asks are different 
than as stated (because of the one in/one out assumption):
"How long must a publisher wait after publishing a new key before it 
signs the trust point DNSKEY RRSet with that key?"  Answer is that it 
may begin signing the RRSet immediately upon publication, resolvers will 
not start tracing trust through that key until at least the hold down 
time.  The publisher may indeed delay signing as long as it wants as 
long as there are other trust anchor keys available.

"How long must a publisher wait after a publishing a new key before it 
revokes an older trust anchor key?"  Answer is that it depends on how 
many trust anchor keys are assumed to be in most resolver's set.  If 
only one, then you wait until you are "reasonably certain that a new key 
has been installed as a trust anchor..."  If its more than one, then it 
depends on the trust point's policy of how many keys to keep more than 
anything.

The important part in this document is getting a handle on the 
publication uptake time for most resolvers given a new key.   The rest 
of the guidance flows from that.

My specific point is that this document should talk to the protocol, not 
limit the discussion to current practices - especially since current 
practices are really a proper subset of the allowed behavior.   I do 
understand what the root is doing right now, and you're both correct 
that I wish they were using at least a two key trust anchor set as 
steady state.  But that still doesn't obviate my point about writing the 
document to the protocol and not the practice.

In the current document, I'd rewrite the math and discussion to deal 
with how I framed the question (e.g. its about how long it takes to 
populate enough resolvers).   If there is then a desire to talk about 
the current root update process, then do that as an appendix or an 
example and I think doing the analysis against the current root key 
update process is a good idea.

Later, Mike




On 5/25/2017 1:15 PM, Paul Hoffman wrote:
> Most people reading an RFC about the DNS probably expect it to be 
> about the public DNS we know. That public DNS currently has one KSK, 
> and there are no plans to change that (although there might be in the 
> future). Given that, and given Mike's comments on the doc, I propose 
> the following.
>
> Change the Abstract from:
>    This document describes the math behind the minimum time-length that
>    a DNS zone publisher must wait before using a new DNSKEY to sign
>    records when supporting the RFC5011 rollover strategies.
> To:
>    This document describes the math behind the minimum time-length that
>    a DNS zone publisher must wait before using a new DNSKEY to sign
>    records when supporting the RFC5011 rollover strategies in zones
>    that have a single key signing key.
>
> Just before Section 1.1, add a paragraph:
>
> This document describes only the case where a zone has only a single 
> key signing key (KSK). It does not apply to zones that have multiple 
> KSKs. The current public DNS has a single KSK covering the root zone, 
> and this document focuses mostly on that KSK in its discussion.
>
> --Paul Hoffman
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop