Re: [DNSOP] CDS and/or CDNSKEY

Warren Kumari <warren@kumari.net> Wed, 09 October 2013 13:44 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 6EE5021F9223 for <dnsop@ietfa.amsl.com>; Wed, 9 Oct 2013 06:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.399
X-Spam-Level:
X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_91=0.6, 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 z8sFd-LbnULF for <dnsop@ietfa.amsl.com>; Wed, 9 Oct 2013 06:44:53 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857FD11E818D for <dnsop@ietf.org>; Wed, 9 Oct 2013 06:44:48 -0700 (PDT)
Received: from [172.26.53.155] (65-121-169-185.dia.static.qwest.net [65.121.169.185]) by vimes.kumari.net (Postfix) with ESMTPSA id 0F8931B401A2; Wed, 9 Oct 2013 09:44:46 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_D4D6673F-EC8D-4AD2-AC87-2E1875C976A3"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <8BD43725-A4CF-4EF7-ABBC-B542E300DC93@iedr.ie>
Date: Wed, 09 Oct 2013 06:44:42 -0700
Message-Id: <E3DC56E8-D33E-41DA-A226-7BCA4F6CDFAD@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> <2777018E-AE0E-4781-AA6C-5F92E46B1CAD@kumari.net> <8BD43725-A4CF-4EF7-ABBC-B542E300DC93@iedr.ie>
To: Billy Glynn <billy.glynn@iedr.ie>
X-Mailer: Apple Mail (2.1510)
Cc: dnsop@ietf.org
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: Wed, 09 Oct 2013 13:44:59 -0000

On Oct 9, 2013, at 4:10 AM, Billy Glynn <billy.glynn@iedr.ie> wrote:

> 
> On 5 Oct 2013, at 19:55, Warren Kumari wrote:
> 
>> 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
> 
> Section 2.2.1
> 
> "The proposal
>    below can operate with both models, but the child needs to be aware
>    of the parental policies."
> 
> also
> Section 6.2.1
> "The
>    DNS Parent needs to publish guidelines for the children as to what
>    digest algorithms are acceptable in the CDS record.
> "
> 
> Maybe I'm missed it... but how would a child be aware of the "parental policies"?	

Thank you, great question.

The way I had envisioned this working was that the human operating the child would "know" because they interacted with the parent when bootstrapping the relationship, and had to enter either the DS or DNSKEY.
I'm also expecting that in general CDS / CDNSKEY records will be published by tools -- the human operating the child ("human child"?) could configure the tool to do do CDS or CDSNKEY -- by default I'd expect the tool to simply publish both, but some children might have religious^W valid[0] reasons for only wanting to publish one of the other.
I'm expecting the the *huge* majority of children will just publish both, and let their parents choose whichever one they want.

This text all appeared in the most recent draft, which was written in a bit of a rush (so I could chat with folk about it at the DNS-OARC meeting / I like rev'ing docs so that folk have something concrete to look at), I'll try make this clearer in the next rev…

W

[0]: For example, there are some children who want to publish two (or multiple) DS records in their parent, and keep one of the DNSKEYs hidden / private / secret. That way, if their key is compromised they can just start signing with the new DNSKEY.






> Billy			     	

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)