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

Warren Kumari <warren@kumari.net> Fri, 07 February 2014 19:22 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 C5D331ACCFF for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 11:22:38 -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 lnHRmkO07K4L for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 11:22:37 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id C71D11A01D2 for <dnsop@ietf.org>; Fri, 7 Feb 2014 11:22:36 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hm4so1166747wib.1 for <dnsop@ietf.org>; Fri, 07 Feb 2014 11:22:36 -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; bh=tAdRGGeYbsIge8D7BsA6TqXuDCMFKNBLMtc0kG6la0g=; b=IbDcEjjX6Ej063CAuOfvE+xg8wSflbML5mFtw8kgVKaq6Chs3Qz5Os9ga/dp0kppwb YBEmaDa91iKR/2NLhOt8FXuLu59Xw/6oANZh8Dj+v83Mm4YPUMYC9zVMbYDaXk8ItND4 fRNZ1sRah2rrrJdO9saTUmjciV+PwX3pTOLgtN+c5YDFTJOL+em8CvvnYTQb2vNzxr/c OGnTj6t+dBr2n7Or6bdqmmHrbn87BeIy3R2rzbwRk/M5ISuUHG3YFuDz1bwiLBGBx1SU Ia6N4BoUaEhKNNAxumbkZXK85IusTsMkndv8B8EB7EzbwADI8BfBiHrS/0Rf2pfbd544 pomw==
X-Gm-Message-State: ALoCoQnIwsahByuFlg/vWfhJK9pwbiXe/jROlPDSiTJYJ2ZnpGl70ThAP+5ODco56QTOWTNXusac
MIME-Version: 1.0
X-Received: by 10.194.58.180 with SMTP id s20mr3307634wjq.54.1391800956113; Fri, 07 Feb 2014 11:22:36 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Fri, 7 Feb 2014 11:22:36 -0800 (PST)
X-Originating-IP: [98.244.98.35]
In-Reply-To: <0D3FD7ED-0A92-4B8E-9619-2B7D84013DD6@hopcount.ca>
References: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com> <CAHw9_i+Jt4Ok+CddheGT_nA=e4srgbUSQy98GeQ9qGn_Cncjag@mail.gmail.com> <52F52215.9090709@dougbarton.us> <CAHw9_i+Aanz5NZVO5Q_x=1zyFzHZSmeU6yoLx3cDkwD2sC-XMA@mail.gmail.com> <52F52386.4070305@dougbarton.us> <0D3FD7ED-0A92-4B8E-9619-2B7D84013DD6@hopcount.ca>
Date: Fri, 7 Feb 2014 14:22:36 -0500
Message-ID: <CAHw9_iLw6+php0bNg4UTm0z2Xf8Luzbx-TRC8xxZBKvGcgz+ew@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Joe Abley <jabley@hopcount.ca>
Content-Type: text/plain; charset=ISO-8859-1
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 19:22:39 -0000

On Fri, Feb 7, 2014 at 2:12 PM, Joe Abley <jabley@hopcount.ca>; wrote:
>
> On 2014-02-07, at 13:18, Doug Barton <dougb@dougbarton.us>; wrote:
>
>> On 02/07/2014 10:14 AM, Warren Kumari wrote:
>>
>>> We are not allowing zones to go from unsigned to signed:
>>
>> Right, and because it says not to do it in the RFC no one is going to do it? :)
>
> I don't see how it would work. The parental agent has no automated way to trust the C* RRSets published in a zone with no secure delegation from its parent.
>
No no no... You don't see how it would work *securely*.

We actually say:
"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. "

The thought behind this was that an unsigned child *could* start
publishing a CDS / CDSNKEY record. The child would then "securely,
through some out of band mechanism" (hand wave, hand wave) contact the
parent and they would agree that this is the correct key and the
parent would then manually include it. Please note that A: we say
don't do this, B: the hand-wave, and c: the fact that we are not
specifying how this should happen.

W



>
> Joe
>