Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com> Sat, 08 February 2014 19:06 UTC

Return-Path: <jinmei@wide.ad.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134201A0203 for <dnsop@ietfa.amsl.com>; Sat, 8 Feb 2014 11:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.481
X-Spam-Level: *
X-Spam-Status: No, score=1.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, SPF_NEUTRAL=0.779] autolearn=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 hCgh5aPXPSsy for <dnsop@ietfa.amsl.com>; Sat, 8 Feb 2014 11:06:34 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E1EEE1A055C for <dnsop@ietf.org>; Sat, 8 Feb 2014 11:06:33 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 2211A2383E2; Sat, 8 Feb 2014 19:06:22 +0000 (UTC) (envelope-from jinmei@wide.ad.jp)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F1D3A16004B; Sat, 8 Feb 2014 19:07:02 +0000 (UTC)
Received: from jmb.jinmei.org (99-115-129-51.uvs.sntcca.sbcglobal.net [99.115.129.51]) by zmx1.isc.org (Postfix) with ESMTPSA id C419016004A; Sat, 8 Feb 2014 19:07:02 +0000 (UTC)
Date: Sat, 08 Feb 2014 11:06:20 -0800
Message-ID: <m27g95zaoj.wl%jinmei.tatuya@gmail.com>
From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei.tatuya@gmail.com>
To: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <C96F9895-3B54-410A-A70E-1D7EF25FB6C0@ogud.com>
References: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com> <CAHw9_i+Jt4Ok+CddheGT_nA=e4srgbUSQy98GeQ9qGn_Cncjag@mail.gmail.com> <CAJE_bqc5gpEEx-OkkXv0dtsTQ6pwYb9kkEzELfvszz30+tvCPg@mail.gmail.com> <C96F9895-3B54-410A-A70E-1D7EF25FB6C0@ogud.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Feb 2014 19:06:35 -0000

At Fri, 7 Feb 2014 13:26:53 -0500,
Olafur Gudmundsson <ogud@ogud.com>; wrote:

> > In that, technically, an empty CDS / CDNSKEY RRset should mean the DS
> > RRset at the parent should be empty.  I have no problem with treating
> > an empty set as an exception, but I think it would help if the draft
> > explains that more explicitly.
> 
> Semantics semantics,  
> No we are defining the semantics to be "IF C* is published parent DS should mirror that,
> if no C* in child --> parent has no action to perform" 

Yes, I now understand that.  Please see my latest response to Warren;
I still think it helps to clarify that explicitly.

> > I'd also note that "absence of CDS" (or CDNSKEY) cannot happen once
> > one such RR is published, and it should mean something erroneous (most
> > likely an operation error at the child or a bug in its tool).  I think
> > it's worth noting in Section 4.1
> 
> Why?
> Here is a perfectly fine time line
> <At start parent DS reflects key A and child uses A to sign DNSKEY RRset> 
> 
> Child publishes CDS with A and B 
> Parent updates DS to reflect A and B 
> Child deletes CDS   

Right, I was still a bit confused here.  Now I understand it, but I
also wonder why would the child deletes the CDS's (again, please see
my latest response to Warren).

> Do you think it is helpful to add an appendix with some examples of use of C* records ? 

Yes, I think so (I don't think I wouldn't need the example myself now
that I understand it, but I guess it helps other fresh readers:-).

> > Finally, I'd suggest explicitly clarifying that CDS / CDNSKEY cannot
> > be used for a child from signed to unsigned (since it would have to
> > remove all CDS / CDNSKEY records to do so).  And, I suspect this is a
> > "MUST NOT", unlike the case of initial enrollment described in Section
> > 9, because this would break interoperability.
> > 
> 
> In theory we can use C* to perform the Going-Unsigned operation, and earlier version of this
> document proposed that, but people objected and we removed that text. 
> We explicitly outlaw going from Unsigned --> Signed w/o some out-of-band validation. 

That's fine.  I just tried to point out that (even if allowed)
"removing all *Cs as a signal of signed->unsigned" and the "no change
if no *Cs rule" can't coexist.

--
JINMEI, Tatuya