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

Olafur Gudmundsson <ogud@ogud.com> Fri, 07 February 2014 18:26 UTC

Return-Path: <ogud@ogud.com>
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 9703B1ACCE9 for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 10:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 9a7AttGesKz6 for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 10:26:53 -0800 (PST)
Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) by ietfa.amsl.com (Postfix) with ESMTP id AB8C51ACCDE for <dnsop@ietf.org>; Fri, 7 Feb 2014 10:26:53 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6A5411B80B0; Fri, 7 Feb 2014 13:26:53 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id C5EDF1B8083; Fri, 7 Feb 2014 13:26:52 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <CAJE_bqc5gpEEx-OkkXv0dtsTQ6pwYb9kkEzELfvszz30+tvCPg@mail.gmail.com>
Date: Fri, 7 Feb 2014 13:26:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
X-Mailer: Apple Mail (2.1510)
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: Fri, 07 Feb 2014 18:26:55 -0000

On Feb 7, 2014, at 12:18 PM, 神明達哉 <jinmei@wide.ad.jp>; wrote:

> At Thu, 6 Feb 2014 14:13:05 -0500,
> Warren Kumari <warren@kumari.net>; wrote:
> 
>> At time T+3 the child sees that the parent has published the new key
>> information ( and the standard keyroll stuff has all happened (records
>> are signed with new key, waited for old TTLs to expire, etc)) and so
>> wants to remove the old key.
>> ** This is, as far as I understand, what you were  asking about)
> 
> Yes, and...
> 
>> The child now publishes just the new key info. They stop publishing the old one.
>> Parent:
>>  example.com. 300  IN DS 31589 8 1 123456......
>>  example.com. 300  IN DS 31589 8 1 789ABC......
>> Child:
>>  example.com. 300  IN CDS 31589 8 1 789ABC......
>> [ Child is only publishing new record / they stop publishing the old one ]
>> 
>> At time T+4 the parent checks agin (it polls, the human clicks the
>> button on the web page, some other trigger happens, etc):
>> It sees that what the child has published does not match what the
>> parent currently has, and so it copies the contents from the child.
>> Parent:
>>  example.com. 300  IN DS 31589 8 1 789ABC......
>> Child:
>>  example.com. 300  IN CDS 31589 8 1 789ABC......
>> [ The child and parent are back in sync. The old key (123456...) is no
>> longer in use anywhere. ]
> 
> ...this makes sense, and actually matches what I first thought was the
> intent of the draft.  With this clarification I guess my confusion
> mainly came from the first sentence of Section 4.1:
> 
>   Absence of CDS / CDNSKEY in child signals "No change" to the current
>   DS set.
> 
> Now I understand this is intended to mean "absence of CDS / CDNSKEY
> *RRset*", i.e., absence of any CDS / CDNSKEY.  But it was not super
> clear when I first read it and it could also mean the absence
> (removal) of this CDS at time T+4
> 

Jinmei thanks for pointing this out 
yes you are absolutely right and I have added the word "RRset" into this sentence. 
I'm reading the rest of the document to make sure we are clear in all places 
like this one. 


>  example.com. 300  IN CDS 31589 8 1 123456......
> 
> maybe I was the only person who was confused about this, but it
> wouldn't do any harm to clarify the wording.
> 
> My original question is now resolved, but I have now another about the
> "absence of CDS / CDNSKEY"...
> 
>> This means that you can use this to update / replace / remove existing
>> DS records (if you have keys A, B, C and D and want to stop using C,
>> you simply publish A, B, D), but you cannot remove *all* DS records /
>> go unsigned.
> 
> This is fine, but technically doesn't it contradict Section 3?
> 
>   The CDS / CDNSKEY record is published in the child zone and gives the
>   child control of what is published for it in the parental zone.  The
>   CDS / CDNSKEY RRset expresses what the child would like the DS RRset
>   to look like after the change;
> 
> 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" 

> 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   

<child performs key roll over from A to B> 

Child publishes CDNSKEY reflecting B 
Parent changes DS to reflect only B 
Child deletes CDNSKEY 


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

> .
> 
> 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. 

	Olafur