Re: [DNSOP] CDS and/or CDNSKEY

Warren Kumari <warren@kumari.net> Sat, 05 October 2013 18:56 UTC

Return-Path: <warren@kumari.net>
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 0169221F918F for <dnsop@ietfa.amsl.com>; Sat, 5 Oct 2013 11:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 qxlWz-KgoCRH for <dnsop@ietfa.amsl.com>; Sat, 5 Oct 2013 11:55:54 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C99421F90CC for <dnsop@ietf.org>; Sat, 5 Oct 2013 11:55:53 -0700 (PDT)
Received: from dhcp-220-73.meetings.nanog.org (dhcp-220-73.meetings.nanog.org [199.187.220.73]) by vimes.kumari.net (Postfix) with ESMTPSA id 4AC151B401D5; Sat, 5 Oct 2013 14:55:52 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <B9CF170E-6F56-4912-B57C-2DAA6CE88E4C@kumari.net>
Date: Sat, 05 Oct 2013 11:55:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2777018E-AE0E-4781-AA6C-5F92E46B1CAD@kumari.net>
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>
To: Olafur Gudmundsson <ogud@ogud.com>
X-Mailer: Apple Mail (2.1510)
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: Sat, 05 Oct 2013 18:56:00 -0000

On Oct 4, 2013, at 7:35 AM, Warren Kumari <warren@kumari.net> wrote:

> 
> I'm planning on just tossing the CDS and CDNSKEY option into the draft on a plane this afternoon, and folk can have a look and see how they feel about this. To my mind the CDS + CDNSKEY seems by far the cleanest option.
> 

Done. 

I have just published -05. 
This version has both the CDS and CDNSKEY records, and some rules for what you do with them.

I personally find this the most attractive option -- it allows those who want DS to accept DS and those who prefer DNSKEY to take DNSKEY.  It keeps the record formats identical to the records that they represent (which, IMO makes implementation simpler), etc.

So, would like to get some feedback on this version -- I understand that it might not please everyone, such is the nature of compromise.

W

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.



> W
> 
>> 
>> 	Olafur
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> --
> It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett
> 
> 

--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I care."  -- Terry Prachett