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

"Paul Hoffman" <paul.hoffman@vpnc.org> Thu, 25 May 2017 17:15 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 336FB1293F9 for <dnsop@ietfa.amsl.com>; Thu, 25 May 2017 10:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=no
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 XPd_Ox_5IP5G for <dnsop@ietfa.amsl.com>; Thu, 25 May 2017 10:15:43 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2E62F127444 for <dnsop@ietf.org>; Thu, 25 May 2017 10:15:43 -0700 (PDT)
Received: from [169.254.97.229] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v4PHFCRY033488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dnsop@ietf.org>; Thu, 25 May 2017 10:15:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.97.229]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Date: Thu, 25 May 2017 10:15:40 -0700
Message-ID: <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org>
In-Reply-To: <ybl60gq9bq2.fsf@wu.hardakers.net>
References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <ybl60gq9bq2.fsf@wu.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gp-5O7Z7hUMffQElCEjNNcSPkiM>
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 17:15:44 -0000

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