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

Warren Kumari <warren@kumari.net> Fri, 07 February 2014 18:14 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 BE3DB1ACC8B for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 10:14: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 bR4odbYWS255 for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 10:14:40 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FC1ACCE4 for <dnsop@ietf.org>; Fri, 7 Feb 2014 10:14:40 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id l18so2478206wgh.11 for <dnsop@ietf.org>; Fri, 07 Feb 2014 10:14:39 -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=ZqD28IzAFH6ZFLZQoinvFAUANvbbi8J+hpLzXq2pCRk=; b=elxzYZ37mwOHnJtxfEluzsEtfaPeCVqPREXNK4vvnBOPoZr5YFK3tETj8gm8wm5zf9 YM/GjYPyGy8t9T6/95zAp5aILXDHzLF2p0vbwhUC3x4SQQ5W/2LCegPYRrQkmsqsJ0xa auZfKM1sFn6fFZTX6CKXtI1xqY19krVe4m1ujY/FRt12t52JqWJvN315s2Zl1UaEuQIv CXOo+eIDl/KNM693cnznKqPmMfu2NB8lm6y9mXm5AqinOe3pBmytpw+V5n6I+xZp8ScB N3QLSqIdYrd0+hkdOGqMuwnM2XLGWON5BwuU4+PtFNk93MGuMlGqh9fySayH2sOhBru4 SfdA==
X-Gm-Message-State: ALoCoQljq9OmqNyFgdQ8t4WmzzVUBbRPmumHvx34smb8XI+u0PMtXDl+o8mXPfaMj6jgMrDPbmVB
MIME-Version: 1.0
X-Received: by 10.180.19.65 with SMTP id c1mr830338wie.39.1391796879584; Fri, 07 Feb 2014 10:14:39 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Fri, 7 Feb 2014 10:14:39 -0800 (PST)
X-Originating-IP: [98.244.98.35]
In-Reply-To: <52F52215.9090709@dougbarton.us>
References: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com> <CAHw9_i+Jt4Ok+CddheGT_nA=e4srgbUSQy98GeQ9qGn_Cncjag@mail.gmail.com> <52F52215.9090709@dougbarton.us>
Date: Fri, 7 Feb 2014 13:14:39 -0500
Message-ID: <CAHw9_i+Aanz5NZVO5Q_x=1zyFzHZSmeU6yoLx3cDkwD2sC-XMA@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Doug Barton <dougb@dougbarton.us>
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 18:14:41 -0000

On Fri, Feb 7, 2014 at 1:12 PM, Doug Barton <dougb@dougbarton.us>; wrote:
> On 02/06/2014 11:13 AM, Warren Kumari wrote:
>>
>> 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.
>
>
> If we're willing to allow zones to go from unsigned to signed via CDS, why
> not go from signed to unsigned? Both situations represent DOS vectors via
> MITM.

We are not allowing zones to go from unsigned to signed:
"This document does not address the initial configuration of trust
anchors for a domain."
and
"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."

W

>
> Doug
>