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

JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com> Sat, 08 February 2014 18:59 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 615AC1A055C for <dnsop@ietfa.amsl.com>; Sat, 8 Feb 2014 10:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level:
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uu-qyPMp-2v0 for <dnsop@ietfa.amsl.com>; Sat, 8 Feb 2014 10:59:33 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D5F061A0451 for <dnsop@ietf.org>; Sat, 8 Feb 2014 10:59:33 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1C0A3C9423; Sat, 8 Feb 2014 18:59:22 +0000 (UTC) (envelope-from jinmei@wide.ad.jp)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 8 Feb 2014 18:59: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 7593016004E; Sat, 8 Feb 2014 19:00:03 +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 4395216004B; Sat, 8 Feb 2014 19:00:03 +0000 (UTC)
Date: Sat, 08 Feb 2014 10:59:20 -0800
Message-ID: <m28utlzb07.wl%jinmei.tatuya@gmail.com>
From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei.tatuya@gmail.com>
To: Warren Kumari <warren@kumari.net>
In-Reply-To: <CAHw9_iJ-_UBzqjgMU9MG-o7afV_jSshX9CZPKxN0X_4n_G0tQw@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> <CAHw9_iJ-_UBzqjgMU9MG-o7afV_jSshX9CZPKxN0X_4n_G0tQw@mail.gmail.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
X-DCC--Metrics: post.isc.org; whitelist
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 18:59:36 -0000

At Fri, 7 Feb 2014 13:43:27 -0500,
Warren Kumari <warren@kumari.net>; wrote:

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

(Now that I've understood the intent I may not be in a good position
for judging the clarity of the text, but anyway) Yes, I think so.

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

Mathematically I think so, but in any case, the point here is to make
the draft so it won't be misunderstood, rather than try to give
a mathematically perfect definition.  In that sense I think it's
sufficient as long as it's clear that "the fact that there are no CDS
/ CDNSKEY records in the child does *not* mean that DS records should
be removed from the parent" around this text of Section 3.

   The
   CDS / CDNSKEY RRset expresses what the child would like the DS RRset
   to look like after the change;

For example, we could say something like "note, however, that the
absence of CDS / CDNSKEY RRset does not mean that the DS RRset be
removed (see Section 4.1)".

This additional note might be too obvious and sound redundant for some
people, but it would help readers like me to avoid possible confusion.

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

Sorry, it was actually me who was confused.  When I made this comment
I thought the only possible case where the child zone admin removes
all CDS is an (incorrect) attempt of going unsigned.  That's why I
said "it should mean something erroneous".  With this being
clarified...

[...]

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

...note the "once one such RR (= CDS/CDNSKEY) is published" part of my
original comment.  It's about the case where all CDS/CDNSKEY RRs are
removed, and is different from the scenario of the lazy child admins.

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

Note that I'm not against the "no change if no CDS / CDNSKEY RRs" rule
at the parent side.  This is a discussion about a child removing all
CDS / CDNSKEY RRs.  My original comment was based on my confusion that
it could only happen when the child (incorrectly) tries to signal to
the parent that it goes unsigned.  Now I understand it *MAY* do it for
some other reason, so this is not necessarily an erroneous
condition...but, at this point I also wonder, mainly just out of
curiosity: what's the intended reason(s) for the child to do that?  If
there's no specific purpose for the operation but it's allowed (as a
MAY) just to give the child the flexibility, isn't it better to say
"the child MUST NOT (or if it's too strong, SHOULD NOT) remove all CDS
/ CDNSKEY RRs"?  Then, even if the parent side of operation or tool
has a defect and (incorrectly) interprets the removal as the child
going unsigned, that accident will be even less likely to happen.

Just a thought, not a strong opinion.

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

Yes, I think so.

--
JINMEI, Tatuya