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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 09 March 2011 14:32 UTC

Return-Path: <hallam@gmail.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 0E9AF3A69FB for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 06:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.565
X-Spam-Level:
X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 qrf+LzEv+LSS for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 06:32:45 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 48A533A69F2 for <dnsext@ietf.org>; Wed, 9 Mar 2011 06:32:45 -0800 (PST)
Received: by iyj8 with SMTP id 8so722014iyj.31 for <dnsext@ietf.org>; Wed, 09 Mar 2011 06:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vl0Jmp/lz5labxRJOyOEJZWjIlCnLkXfAk66NzPkfdo=; b=U8i3BLGQBxAJ3RTaZ+qeDKPdv+FFCBf+z4pr7I9H8K2CtXPn4bYQdBbvIFRJfwP/z/ oStd6uiW3vSzfxbepYl7hdMiTYVDA+N5h644xQmwYYXCi4fmZH/TCG1ZjfomKL4c0xof GK9kylwglryczRt2PEM2vhXBuICJac3hf5n8s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xfr3HkXdpDRJEZn7r3WM/KgAuepANnDnZH2yj0olmix7RgMWJ7nrrrhj7fZaHs7ccX l7sb/GYiH1pLrsrg6dhWSCGQO1Awu9Gu1v97TH4NdZ33aqhFayDzM9m+dn63hlTdIfVa AflaKnXSMosR+3fc13lfA5X4t0ZoQrA9BaFVQ=
MIME-Version: 1.0
Received: by 10.42.77.74 with SMTP id h10mr7358202ick.99.1299681241049; Wed, 09 Mar 2011 06:34:01 -0800 (PST)
Received: by 10.43.61.80 with HTTP; Wed, 9 Mar 2011 06:34:01 -0800 (PST)
In-Reply-To: <4D778C86.4020105@ogud.com>
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>
Date: Wed, 9 Mar 2011 09:34:01 -0500
Message-ID: <AANLkTin8EYVhRmRUvu0LQ2cJ_E5RONQQWoCraDdK5Jp5@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Olafur Gudmundsson <ogud@ogud.com>
Content-Type: multipart/alternative; boundary=20cf3005dc06b1ab95049e0d9e61
Cc: 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: Wed, 09 Mar 2011 14:32:47 -0000

Like Olafur, I think that this record may well be useful in the context of
automating key management.

As such, it seems to me that it is quantitatively different from the URI and
CAA proposals for new RRs. In those cases the objective is to support
applications that build on top of DNS. So it is probably best to let them
rise or fall on their own merits. The alternative being for DNSEXT to get
into complicated negotiations and synchronizations with other WGs.


In this case the proposal is really one that addresses the DNS
infrastructure itself and so it may require a somewhat higher degree of
scrutiny.


On Wed, Mar 9, 2011 at 9:19 AM, Olafur Gudmundsson <ogud@ogud.com> wrote:

> <hat="RFC3658-editor">
>
>
> On 09/03/2011 8:30 AM, Scott Schmit wrote:
>
>> On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext:
>>
>>> On Tue, 8 Mar 2011, Roy Arends wrote:
>>>
>>>>
>>>>    D.    Motivation for the new RRTYPE application?
>>>>
>>>>          To allow a copy of the DS RRset [RFC4034] to be published
>>>>          in the child zone, which is used to update the parent DS RRset.
>>>>          It is expected that this will allow the rollover of a key
>>>> signing
>>>>          key to be automated.
>>>>
>>>
>>> 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.
>
>
>
>> 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 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.
>
> <disclaimer>
> I encouraged George to submit this, as I had the same idea about the same
> time as he did, in the context of automating DNS operator change/transfer.
> </disclaimer>
> This record does not change the DNS control plane (resolvers) it is only
> published for information purposes and to be used by zone content management
> tools.
>
>        Olafur
>
> PS: I think that original DNS had NS RRset in two places was the biggest
> design mistake and we have spent lots of time and effort to overcome that.
> This choice was done for expediency and/or optimization reasons. s
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>



-- 
Website: http://hallambaker.com/