Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

Brian Dickson <> Fri, 25 September 2020 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 402993A108D for <>; Fri, 25 Sep 2020 10:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xCr87_z8u1I3 for <>; Fri, 25 Sep 2020 10:39:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 957B33A1083 for <>; Fri, 25 Sep 2020 10:39:47 -0700 (PDT)
Received: by with SMTP id a16so844213vke.3 for <>; Fri, 25 Sep 2020 10:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mkBjRPxDR0GhWHYe6WyI0WLobIfHpP+5chah8hWZNM4=; b=r4/8yDQznLLbvdgjaeN3ygUyRHUUIeqRk5YoaQSwhqqzhP7dbwWgr7FFgtIrYcqadi 2u9znulY637HWtjphNCC6UPyMcbCIm66doE8nTI3+QhNfvMdc/7lCzdBls7iXvEcHu2b Cx4Za3pb/zOwZoNHvW+NE2tlO4fD0llbi7xlK8okY14fubCmFa6Pc8SQ+pnDyvqk3LEZ MFs18ZkFLgBN+sh7G0Zmrbjb3p63q1l57FxkfcAoFiJiBbln4xhfnvFYDwhXiCttdURl V57Ku3N3ae5seeYy/CMnukTQUhw0ajRoExirHVkBmVT485rA6LG0NylGi4vEs9/xY7aY VwgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mkBjRPxDR0GhWHYe6WyI0WLobIfHpP+5chah8hWZNM4=; b=SUtePVHDab9gKmgDzqQHCn1qmyJ5b0tifmcrBFJOC2eThZgkYDMqSAV2AfZS8Gt9a5 cvX7PeB+lz2tVej0c6UKizDbcaxzgb1px+DmYLGg0uYOt7DdyFfquZTbh6S1zhrmSlM2 dc5+C7e5Ag9k6DuWj/pK1A13H68kJzSfPhcjFZZq2Q8dWyk34/qk3dd/Rry/XF5lSeFD y0ddbV45wXvqmhItIRYwhMNoFgrlSZCqdPM+NcLbF4OSm1iIWK31hQpeeqG1H2FnkD08 iOQTJ8OP8DTtzgdYjoPZR5bVT3KLfb9bkWX2aXzWAkrFJfe/pBP/nHuMvHcRgnI4skdS bgNA==
X-Gm-Message-State: AOAM533vp30OArKAY1Ef6Lt711eMhOzM5/cG2DVjTDJ3AEIyKoc5hIDN x5644K0vtq5SkB9fpP8uIEHpJCVzTes8lWiwowMTK74YKB4=
X-Google-Smtp-Source: ABdhPJySAf4tefsgRwGo4bhTVpA4gbqA6UEF7C3KZc0vOOzpGZ5GZuW72jeNb6XsY+ImgW1Uq3GH7jq/ZM1/jRm6QMY=
X-Received: by 2002:a1f:2cc:: with SMTP id 195mr560110vkc.2.1601055586461; Fri, 25 Sep 2020 10:39:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 25 Sep 2020 10:39:35 -0700
Message-ID: <>
To: Peter van Dijk <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="0000000000007f2b4205b026cdd3"
Archived-At: <>
Subject: Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Sep 2020 17:39:49 -0000

On Thu, Sep 24, 2020 at 10:58 AM Peter van Dijk <>

> Hello dnsop,
> early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
> of-the-delegation record to hold a pin for authenticating child-side
> DoT servers. This would be undeployable.
> A few months ago, Tim April proposed NS2/NS2T, which looks like it
> would clearly benefit from the ability to publish signed data on the
> parent side of a delegation. This ability seems unlikely today.
> Also a few months ago, myself and a few others proposed shoehorning
> certificate hashes into the DS record. The shoehorning (and perhaps
> some other aspects of that proposal) were not well received by
> everybody.
> When talking to Petr Spacek about this, he came up with the following:
> -if-, long enough ago, besides DS, a range of RRtype numbers would have
> been reserved with the same processing rules, i.e. these types live in
> the -parent- and not on the -child-, then both DSPKI and NS2T could
> become parent side records through the simple act of requesting an
> IANA allocation from that special range.
> Sadly, it is not five years ago today. It is today today. So, here is a
> draft that requests that IANA reserves such a range. Knowledge of that
> range and its DS-like handling can then end up in implementations over
> time. When that has happened at some useful scale, we could do a DSPKI
> experiment. NS2T could explore what benefits come from the ability to
> publish in the parent. And, nobody will have to shoehorn hashed TLS
> certificates into DS records.
> This draft is a bit rough; I trust it, and this email, have brought the
> idea across. Editorial comments are welcome via GitHub (link is in the
> draft), or via the WG of course.
> Looking forward to your thoughts on this.

The motivating use cases to justify this, were flawed in a number of ways.

One of those (IMHO, the biggest flaw) was that the pertinent information in
was often an attribute of the name server serving the zone, rather than a
zone attribute.

And, for reasons very similar to the problems in the recent draft on
publishing information
on the authority servers in their zone (draft-pp-dnsop-authinfo), there are
in the mapping relationship from zones to nameserver IPs to physical

These schemes only work under a small subset of conditions, and as such,
are not
useful as a standardized method. The simplest scenario for a zone, is where
zone is managed by the domain owner, served only on name servers run by the
owner, with name server names which are exclusively in the domain in
Any situation that does not fall into that scheme, not only won't work, but
would impose
significant operational challenges in attempting to maintain the suggested

This doesn't even address the significant challenges of developing a method
of passing
the information from the domain owner (registrant) to the parent name
server (registry).
The current mechanism of EPP, does not even accommodate the DNS operator
the DNS operator is also the registrar.

This doesn't mean that there isn't interest in some of the related
problems, only that the
solutions that have been discussed, including this one, either won't work,
won't scale,
or can't be deployed.

The lack of a dedicated RRTYPEs for the parent side is thus a moot problem.

I concur with Paul Wouters that these would also be particularly dangerous
and problematic.