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

Warren Kumari <warren@kumari.net> Fri, 07 February 2014 18:43 UTC

Return-Path: <warren@kumari.net>
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 1D40C1AC7F2 for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 10:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Zh7ee9jI3-5y for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 10:43:39 -0800 (PST)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 08BD81ACCF5 for <dnsop@ietf.org>; Fri, 7 Feb 2014 10:43:27 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hm4so1129754wib.14 for <dnsop@ietf.org>; Fri, 07 Feb 2014 10:43:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UmceSI0sBznbOVD59D2DU5/CWMOZvDiHUXwo6Aon2wI=; b=PWC2sukj5U3oriWghskk4TKls0Su9PkPuLmxYi0Opx7g/2CsHLrZlkrh5P9uGQqBEX Xef04oiA1TOvfMvpMxKzz+kWNx61jkzN8jiPtZnaVziHD//2V6e5d0GL/dtRQK1+AQPB 3es1RMFarUTvy0ztPy9V/HkXGW6WxE2QXdQZErg2P5QdhZ7kHWnQlSONaIsGpOE6s1rY yOidhE88w5SzElA+sCFvsENoVH5htgRHKGNHH9tswYKyMJ4pLhCAniKHJgl2YcDmm3S3 bMP1B/SpVo/qRLEX7bbYmU1PJGl/+7FQN1sFsFlT1sfcEfCoVI0Tde2/E9sg8/egvrSN 7u/A==
X-Gm-Message-State: ALoCoQm4T78l/Z2uk0+n5nLf+rL2Q8VrbXO0N6A6SYZyV0X9HsT5kqa0FNn3NB4TnCEyVtDqN6gC
MIME-Version: 1.0
X-Received: by 10.180.37.193 with SMTP id a1mr1011683wik.52.1391798607395; Fri, 07 Feb 2014 10:43:27 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Fri, 7 Feb 2014 10:43:27 -0800 (PST)
X-Originating-IP: [98.244.98.35]
In-Reply-To: <CAJE_bqc5gpEEx-OkkXv0dtsTQ6pwYb9kkEzELfvszz30+tvCPg@mail.gmail.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>
Date: Fri, 7 Feb 2014 13:43:27 -0500
Message-ID: <CAHw9_iJ-_UBzqjgMU9MG-o7afV_jSshX9CZPKxN0X_4n_G0tQw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
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:43:41 -0000

On Fri, 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
>
>   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.
>

Yup, the wording was unclear / ambiguous.
I tried "The absence of *any* CDS..." but that was also unclear. I
also tried "Absence of a CDS / CDNSKEY *RRset* in child...", but ended
up settling on:
"If there are no CDS / CDNSKEY resource records in the child, this
signals that no change should be made to the current DS set. This
means that, once the child and parent are in sync, the child DNS
operator MAY remove all CDS records from the zone."
It this better?


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

Yup. I'm currently trying to craft text to that effect. Unfortunately
I'm having a hard time doing so cleanly.
I've just added "An empty CDS / CDNSKEY RRset means that no change is
needed." in my edit buffer, but I'm unclear on something -- is an
empty RRset the same as a non-existing RRset? I *think* it is, but it
somehow feels weird...

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

Um, I think I'm confused now.
Absence of CDS / CDNSKEY can happen. The child just stops including
CDS / CDNSKEY records in their zone - this signals "No change", and is
a special case.

Some background / justification for this:
Let's say that example.com is a company that sells Examples for use in
presentations. They have a few departments (accounting, sales and
development) who each run their own DNS servers, and currently have
the following in their zone:

accounting.example.com IN DS 1 1 12345...
sales.example.com   IN DS 1 1 6789....
development.example.com IN DS 1 1 ABCD123...

The IT group (who runs the main example.com nameservers) get tired of
each department rolling keys and asking for their DS to be updated, so
they decided to start using CDS for this. They mail the DNS person in
each department and say "Starting April 1st we will be supporting CDS,
so you can manage your own stinking DS records without us having to do
any work".

The accounting and development groups read this, shout "Yay!, no more
having to deal with the rude IT folk", and start publishing CDS
records.
The folk in the sales group are wither off playing golf, or see the
April 1st date and figure it's a very subtle joke. Anyway, they don't
bother publishing a CDS record....

If the "Empty CDS / CDSKEY RRset == no change" rule did NOT exist (or
if "Empty CDS / CDSKEY RRset" meant please go unsigned), what would
happen would be that, on April 1st the IT group would turn on some
home grown CDS tool. It would go off and look at all the child zones.
If would be happy with accounting,example.com and
development.example.com. For sales it would see no CDS record, and so
would "helpfully" remove all DS records, making the sales.exmaple.com
zone be unsigned.

Yes, there could be all sorts of logic built into the tool to keep
state / a record of which zones had opted into using CDS / CDNSKEY,
but this is a: error prone and b: requires state on the parent.


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

I just added:
"While it may be tempting, this SHOULD NOT be used for initial
enrollment of keys since there is no way to ensure that the initial
key is the correct one. If is used, strict rules for inclusion of keys
like hold down times, challenge data inclusion etc., ought to be used,
along with some kind of challenge mechanism. A child cannot use this
mechanism to go from signed to unsigned (publishing an empty CDS /
CDNSKEY RRset means no-change should be made in the parent)."

Is this clear? I suspect I'm missing some subtleties here.

W



> --
> JINMEI, Tatuya