Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]
Brian Dickson <brian.peter.dickson@gmail.com> Fri, 25 September 2020 18:06 UTC
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E700A3A1407 for <dnsop@ietfa.amsl.com>; Fri, 25 Sep 2020 11:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 G4IlIkskDBCQ for <dnsop@ietfa.amsl.com>; Fri, 25 Sep 2020 11:06:02 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1E73A140B for <dnsop@ietf.org>; Fri, 25 Sep 2020 11:06:02 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id j3so1925908vsm.0 for <dnsop@ietf.org>; Fri, 25 Sep 2020 11:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LI2FeF6MXUERSjzdMs3cR0/aJw4Txig17xheKmcYXLo=; b=tEYz3uuqiDLaU59VyxwX7ve18CAQvyH+cpe9lQIfZDctW/63j0Xq4Q0melOW/Y4P22 3a/OckTpYbH1Gh1kRJEN6XI0LYJvOnWNljjLAblccSWZAAR+TrMsVyXDKg4z4+taWib3 A0UXHtbNWPB5yW5MWC3XXQHyYVmJbGLedPw5U3qQjjNevKzaUJwRPTdxm8PHqomSx/oK Ee5arIFUUN2xwArSt75dWweTBhAjNbn8A8RJ/sQbu3fJw3FX6NPuS6NNEaLwtot4IgET NXRGIdPEihLigqrGU2QCC5JEzQezxdMh3Gy504CfvI6vLEQKRepaLvxKUe0t3vndyRUz lCbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LI2FeF6MXUERSjzdMs3cR0/aJw4Txig17xheKmcYXLo=; b=g5kqlX+mXIyafwtjmlHznl+PNaWJT52hC0I2/4qrWV0qtTb1/evOFA+9UwVUaJmkyi Kz7Kx3r98NsVeRT8X+uQLzQF2FpQ09mTO5by7qu366ZQHuXe4PeFWeB4/4RKqdxAGM0i l7DsZmluPnDftuw9QOKgWUdfq39P7AEJ+eciCdrFVOoX2MBDZ6C9dpYN5Qc1fN2bN02j USmYQdTMWWTaSdaUAgWc/DRd0LSGi8ZGBQV0NdVy3fH0CD56zLqSDe7ds6FC6j0MnwxQ iipERTON2tKywQdeqkZ/kkpCJ4PnC1jKR6mGKNCRSJNHpH5/E1KsUTnkuK52km8tqJds wGZQ==
X-Gm-Message-State: AOAM530b1KcgMoY1uipOlEbwDEfVzKyhTfBgZGAuZMJ6d0vSvgqckCDt v6JYhZnjYdMBhIQaaYWbKFtaxrO1oJJM3fTpCC8=
X-Google-Smtp-Source: ABdhPJzEdS8Qu4ZI98T1hQTJUYfxIc8H8I/2k5Fk888HuBffQzuAhnMKgy1Oy8EUsvc2JuEaoO0QDmWCpGIT2McvLgg=
X-Received: by 2002:a67:1d86:: with SMTP id d128mr550602vsd.58.1601057161425; Fri, 25 Sep 2020 11:06:01 -0700 (PDT)
MIME-Version: 1.0
References: <160103718726.30054.5094716283741232929@ietfa.amsl.com> <026e8a7b7db7279269a361c0fd526283062df212.camel@powerdns.com>
In-Reply-To: <026e8a7b7db7279269a361c0fd526283062df212.camel@powerdns.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 25 Sep 2020 11:05:50 -0700
Message-ID: <CAH1iCiodVX8yHBLzSPJFkfQqc-QXuu1UtQs-kDZKiB104dAw6Q@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f367e05b0272bc9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PX_dadCOOgpcLQTj8LkwIQOgQAY>
Subject: Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Sep 2020 18:06:04 -0000
On Fri, Sep 25, 2020 at 5:36 AM Peter van Dijk <peter.van.dijk@powerdns.com> wrote: > Hello dnsop, > > in this new episode of 'enabling future innovations that we perhaps > cannot even imagine today', please find below a link to a draft > proposing a DS digest type that does no digesting at all. This allows a > zone owner to publish information in the parent zone and have the > parent sign that data on the owner's behalf. > No. Please read all of rfc5507, and in particular section 5, on why this goes against IAB guidance, years of operational and developer experience, and is a horrible, horrible idea. Do not overload (re-use) RRTYPEs, period. Also, beyond the potential use case of having parent-side non-authoritative data DNSSEC signed, by using a different RRTYPE for the delegation side of a zone cut, and having a way of discriminating glue records (such as A and AAAA) from non-glue equivalents, so that the parental size of a zone cut can DNSSEC sign these records, the entire design of the Domain Name System is built around the delegation principal, which is that the only place data is authoritative is below a zone cut. Having the ability to push data up to the parent side, which is controlled by the child side, violates the implied security model of the relationships between zones, which roughly correspond to the relationship in the Unix file system of directories, symbolic links, and mount points. The corresponding mechanism would be to allow an unprivileged user to "give away" ownership via the "chown" command, to a privileged account. This capability was extensively abused in the Unix world until it was blocked. Implementing this mechanism in DNS would almost certainly be abused in similar ways, with the same end result, of having to disable that mechanism due to abuse. This is reason enough not to even start down this road. I'm happy to provide example use cases, but don't want to distract from the general model being bad, by playing whack-a-mole on examples and retorts. (See Warren Kumari's email signature line about pants and weasels for why.) With respect and no offense intended. Brian
- [DNSOP] [Fwd: New Version Notification for draft-… Peter van Dijk
- Re: [DNSOP] [Fwd: New Version Notification for dr… Brian Dickson
- Re: [DNSOP] [Fwd: New Version Notification for dr… Paul Wouters
- Re: [DNSOP] [Fwd: New Version Notification for dr… Peter van Dijk