IETF Logo Mail Archive

Re: [DNSOP] CDS and/or CDNSKEY

Ondřej Surý <ondrej.sury@nic.cz> Fri, 11 October 2013 07:50 UTC

Return-Path: <ondrej.sury@nic.cz>
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 AA79D21E809C for <dnsop@ietfa.amsl.com>; Fri, 11 Oct 2013 00:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf1x0YPU5+Wi for <dnsop@ietfa.amsl.com>; Fri, 11 Oct 2013 00:50:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7851021F943C for <dnsop@ietf.org>; Fri, 11 Oct 2013 00:50:44 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:1012:ca3d:979c:8f26] (unknown [IPv6:2001:1488:fffe:6:1012:ca3d:979c:8f26]) by mail.nic.cz (Postfix) with ESMTPSA id F352D13FA04; Fri, 11 Oct 2013 09:50:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1381477843; bh=HdeQrfRmbSAcfPtk3N22ipzBSE/rvshydfUBo+N48/U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Yq7+4807kqGmQ2CA+kdQFLdf9SRPmBH8uSlsmoECW0v7qXSVnRv9zBSjALMrJzWqq BsEXKQVwK86nrtRuZ6ifeVa6QrzVL/4qXl1F1G640eFTmFctfC5GloDEZgArWGnRee 9xZoKb0qdpPP40pd83CD7UIuXYvq2nu9ykeWxeDg=
Content-Type: multipart/signed; boundary="Apple-Mail=_6FFFEC93-D9D3-4A2C-9453-726919A51564"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ondřej Surý <ondrej.sury@nic.cz>
In-Reply-To: <2777018E-AE0E-4781-AA6C-5F92E46B1CAD@kumari.net>
Date: Fri, 11 Oct 2013 09:50:42 +0200
Message-Id: <6D09907E-D290-4D31-8D35-F7C1F647171D@nic.cz>
References: <CE7257AA.D9AD%bdickson@verisign.com>, <alpine.LFD.2.10.1310022330290.21614@bofh.nohats.ca> <201310031159387926584@cnnic.cn> <524D128A.5050701@nlnetlabs.nl> <F4E5DA98-0A19-4E0A-AF27-0FC83F7A560A@kumari.net> <alpine.LFD.2.10.1310031606040.28168@bofh.nohats.ca> <524E5747.3020708@nlnetlabs.nl> <C5EB17D8-80AB-4FCF-85B5-09EDBCA419E6@ogud.com> <B9CF170E-6F56-4912-B57C-2DAA6CE88E4C@kumari.net> <2777018E-AE0E-4781-AA6C-5F92E46B1CAD@kumari.net>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.1510)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: dnsop@ietf.org, Paul Wouters <paul@nohats.ca>, Matthijs Mekking <matthijs@nlnetlabs.nl>
Subject: Re: [DNSOP] CDS and/or CDNSKEY
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 11 Oct 2013 07:50:45 -0000

On 5. 10. 2013, at 20:55, Warren Kumari <warren@kumari.net> wrote:
> Filename:	 draft-kumari-ogud-dnsop-cds
> Revision:	 05
> Title:		 Automating DNSSEC delegation trust maintenance
> Creation date:	 2013-10-05
> Group:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-05.txt
> Status:          http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
> Htmlized:        http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-kumari-ogud-dnsop-cds-05
> 
> Abstract:
>  This document describes a method to allow DNS operators to more
>  easily update DNSSEC Key Signing Keys using DNS as communication
>  channel.  This document does not address the initial configuration of
>  trust anchors for a domain.  The technique described is aimed at
>  delegations in which it is currently hard to move information from
>  the child to parent.


I fully support this to go ahead, although I disagree with some parts of the document.

One (not so strong) thought – it might be actually good to split the "requirements" and the "protocol" part into separate documents.

E.g. split sections 1 and 2 (+ Appendix A) to separate 'Informational' document and create new 'Standards' document from the section 3 to the end of the document.

Some other comments:

Section 6.2 second paragraph:

I would add an recommendation to check the CDS/CDNSKEY value for <n>-consencutive CDS/CDNSKEY TTL times to ensure that the change is valid.  (Where <n> is something like <2,...> per parent local policy).

Section 6.3 third paragraph:

The usual mechanism is the NOTIFY email in the registry, and the owner of the object is notified of any change of the affected object.  Thus it seems to me that this paragraph is not needed.

Otherwise lgtm.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

v2.23.0 | Report a Bug | By Email