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

Mark Andrews <marka@isc.org> Thu, 10 March 2011 01:12 UTC

Return-Path: <marka@isc.org>
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 E06F53A6B20 for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 17:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 m182wkQG6JYt for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 17:12:24 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 56BC03A6A3F for <dnsext@ietf.org>; Wed, 9 Mar 2011 17:12:24 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id B9C29C9427; Thu, 10 Mar 2011 01:13:31 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3A070216C1E; Thu, 10 Mar 2011 01:13:31 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2BE0EC03244; Thu, 10 Mar 2011 12:13:28 +1100 (EST)
To: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
From: Mark Andrews <marka@isc.org>
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><DD056A31A84CFC4AB501BD56D1E14BBB9CC7CB@exchange.secure64.com>
In-reply-to: Your message of "Wed, 09 Mar 2011 17:41:25 PDT." <DD056A31A84CFC4AB501BD56D1E14BBB9CC7CB@exchange.secure64.com>
Date: Thu, 10 Mar 2011 12:13:27 +1100
Message-Id: <20110310011328.2BE0EC03244@drugs.dv.isc.org>
Cc: dnsext@ietf.org, Olafur Gudmundsson <ogud@ogud.com>
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 01:12:26 -0000

In message <DD056A31A84CFC4AB501BD56D1E14BBB9CC7CB@exchange.secure64.com>om>, "Ste
phan Lagerholm" writes:
> 
> 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.

Adding new types shouldn't be expensive if you have designed your
applications to be extended from the begining and any application
dealing with arbitary DNS records should be so designed.

> 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
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org