Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

"Stephan Lagerholm" <stephan.lagerholm@secure64.com> Thu, 10 March 2011 00:47 UTC

Return-Path: <stephan.lagerholm@secure64.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AA43A698A for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 16:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js58yirhAXto for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 16:47:03 -0800 (PST)
Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 5AC6B3A67D9 for <dnsext@ietf.org>; Wed, 9 Mar 2011 16:47:03 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 0CC3CB837E; Wed, 9 Mar 2011 17:42:02 -0700 (MST)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBv2Z-YWIOGP; Wed, 9 Mar 2011 17:42:01 -0700 (MST)
Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 1693EB8377; Wed, 9 Mar 2011 17:42:01 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299717721; bh=Y2bbCor6CJ53fZxJR13y7A1k89DllrucPWXCC8kMIdI=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=ucSbDUuH0JwZ8kjcncCJg TAMf9AlbcpsA7ICAH/tMHPJQz1fo+BZkggOvV/gZR6KBmpf/lNJEn3GpysTpgjJx6Yy J9i5UmnuZIQIDS+HgxPPWg0TsrCEsdIpcWRRVhLpK1ku50xAKnMiOtNkAoAncEgZIpV 3N0pfWdc+RLFPFhA=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 9 Mar 2011 17:41:25 -0700
Message-ID: <DD056A31A84CFC4AB501BD56D1E14BBB9CC7CB@exchange.secure64.com>
In-Reply-To: <4D778C86.4020105@ogud.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
Thread-Index: AcveZCr4gZyNY42tTme1s+UeMVnddAAVuXxw
References: <C99C3502.72B1%roy@nominet.org.uk> <alpine.LSU.2.00.1103082030190.5244@hermes-1.csi.cam.ac.uk><20110309133017.GA19809@odin.mars.sol> <4D778C86.4020105@ogud.com>
From: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
To: "Olafur Gudmundsson" <ogud@ogud.com>, <dnsext@ietf.org>
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2011 00:47:04 -0000

On Wednesday, March 09, 2011 8:20 AM Olaf Gudmundsson wrote:
>>> Why not just use the child zone's SEP DNSKEY RRs for this purpose?
>>
>> I'm inclined to agree with this, but even if it's decided that the
>> DNSKEY RRs aren't sufficient, why not just use DS on the client side?
I
>> see that RFC 3658 forbids it, but I'm not sure I understand why.  We
>> don't have CNS in addition to NS, so why should DS be different? I
can
>> understand that DS must be ignored by a client unless it's signed by
the
>> parent, but if that check doesn't already exist, we're already in
>> trouble.
>
>Using SEP bits in DNSKEY records does not work when a zone wants to
>retire an algorithm, the DS MUST be removed before the corresponding
>DNSKEY record is removed.
Good point. For the DNSKEY strategy to work, then it would have to be a
new flag.

>> So, maybe they didn't think of the use case this draft is trying to
>> address and forbade it to keep the software implementations simpler?
But
>> that could have been accomplished simply by saying that a DS on the
>> child side is ignored for validation purposes (it now becomes
pointless
>> (but harmless) to include it, except as a way to securely send DS
>> records from the child to the parent).
>
>RFC3658 specified for the first time a record that can only live at the
>parent and this required major changes to resolution algorithm
>implementations.
>If there is anything we have learned in the last 25+ years of DNS is
>this: "If the same information can appear in two places it will not be
>the same and you have no idea which version resolvers will use"
>Just look at what different resolvers do when the parent and child NS
>records differ.
I agree.

>> I can understand the motivation of introducing a new RRTYPE to avoid
>> needing to alter existing MUST NOTs, but CDS just seems unnecessary.
>>
>> Maybe there's another reason to forbid DS on the child side that I've
>> overlooked?
>>
>
>see above, and new types a cheap, and this gives the child full control
>over the changes in the DS in parent. Similarly this can be used to
>update trust anchors for an Island of security.
For whom do you feel that new types are cheap? Any provisioning program
that parses/constructs a zone file will have to be rewritten to be able
to understand this new type to be able to display/add/edit/remove it in
a meaningful way. I disagree that this is cheap.

We are just starting to see support in different tools for DNSKEY and
DS. Hopefully they made the flag field configurable. Adding a new flag
to DNSKEY would be cheaper.

/Stephan