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

From: Peter van Dijk <[email-masked]>
Date: Thu, 24 Sep 2020 19:58:16 +0200

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.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

-------- Forwarded Message --------
From: [email-masked]
To: Petr Spacek <[email-masked]>, Peter van Dijk <
[email-masked]>
Subject: [EXT] New Version Notification for draft-peetterr-dnsop-
parent-side-auth-types-00.txt
Date: Thu, 24 Sep 2020 10:49:03 -0700

A new version of I-D, draft-peetterr-dnsop-parent-side-auth-types-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:		draft-peetterr-dnsop-parent-side-auth-types
Revision:	00
Title:		Parent-side authoritative DNS records for enhanced delegation
Document date:	2020-09-24
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
Status:         https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
Html:           https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
Htmlized:       https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00

Abstract:
   A DNS RRtype numeric range that behaves like DS is reserved.  This
   means: being authoritative on the parent side of a delegation; being
   signed by the parent; being provided along with delegations by the
   parent.  If this document had become an RFC five years ago, deploying
   new types (along the lines of NS2/NS2T, DSPKI or various other
   imagined things like DNS ('signed delegation NS')) would be easier to
   deploy and experiment with today.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Thu, 24 Sep 2020 22:53:17 -0400 (EDT)

[added hrpc to CC: list]

> IANA allocation from that special range.

That is an incredibly dangerous idea. It is basically a wildcard from
the parent to make claims about the child, that the child cannot
control. You can imagine many kind of RRTYPEs that be be used, eg:

ADULT_CONTENT
POLITICAL_SPEECH
GOVERNMENT_BLOCKED
MONITOR_USERS
GEOGRAPHIC_CONSTRAINT

Of course, governments can already dictate that ISPs do any of these
things, but with this proposal you are giving them an awesome censorship
tool. And anyone not complying to the RFCs implementing these, could be
in clear violation of the working of the internet and should be punished.

Letting the parent make arbitrary statements about the DNS child is too
dangerous a tool to roll out.

Partially this can be mitigated by making the registry Internet Standard
Required, but that would put a lot of pressure on IETF and DNSOP later
on - pressure that is not technical in nature, but political.

I understand the desire for "if we need the parent to say something
about the child in the future, we would already have the infrastructure
running". Indeed, it is a neat idea. But too dangerous.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 24 Sep 2020 23:00:13 -0400

Paul,

I would certainly be concerned about such a scenario, but I don't
understand how it's relevant to Peter's proposal.  Couldn't this already be
done today, by simply including such a hypothetical "parent opinion" record
in the glue?

For the scenario you're describing, the present lack of DNSSEC
authentication would not seem to be an obstacle.

--Ben

On Thu, Sep 24, 2020 at 10:53 PM Paul Wouters <[email-masked]> wrote:

> > URL:
> https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
> > Html:
> https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
> > Htmlized:
> https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 25 Sep 2020 10:39:35 -0700

> 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
question
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
problems
in the mapping relationship from zones to nameserver IPs to physical
servers.

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
the
zone is managed by the domain owner, served only on name servers run by the
domain
owner, with name server names which are exclusively in the domain in
question.
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
scheme.

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
unless
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.

Brian

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Sep 2020 21:59:30 +0100

Brian Dickson <[email-masked]> wrote:
>
> 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 unless the DNS operator is also
> the registrar.

Yes, I was going to say something along these lines.

Tangentially I suppose this is a case where the (common) EPP distinction
between domain objects and host objects might (shock, horror) be useful:
maybe we could in principle allow a DNS operator to manage information
about their servers independently of the domains that they host.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lands End to St Davids Head including the Bristol Channel: Northwest 5 to 7,
veering north 4 to 6. Rough at first in southwest, otherwise slight or
moderate. Showers. Good, occasionally moderate.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Sep 2020 17:21:04 -0400 (EDT)

On Thu, 24 Sep 2020, Ben Schwartz wrote:

> I would certainly be concerned about such a scenario, but I don't understand how it's relevant to Peter's proposal. 
> Couldn't this already be done today, by simply including such a hypothetical "parent opinion" record in the glue?
> 
> For the scenario you're describing, the present lack of DNSSEC authentication would not seem to be an obstacle.

middlewhere (voluntarilly or mandated) would not be able to trust glue
for security decisions. where as they might be able to trust parental
signed data.

Of course, any goverment party can publish a list of directives in their
publications and law books, but if those are technically weak or even
formally unprovable, implementation and enforcement will be impossible.

You can also look at it from the reverse way. If the parent wants to
publish anything about the child, even if it received it from the
child, it can already do so using a prefix in its own zone, eg:

_nohats._parentalguidance.ca.	IN DNSKEY <blob>
_nohats._parentalguidance.ca.	IN DS <blob>
_nohats._parentalguidance.ca.	IN TXT <blob>

No DNS infastructure or protocol changes are required for this.

Paul