Subject: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]

From: Peter van Dijk <[email-masked]>
Date: Fri, 25 Sep 2020 14:36:19 +0200

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.

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

-------- Forwarded Message --------
From: [email-masked]
To: Peter van Dijk <[email-masked]>
Subject: [EXT] New Version Notification for draft-vandijk-dnsop-ds-
digest-verbatim-00.txt
Date: Fri, 25 Sep 2020 05:33:07 -0700

A new version of I-D, draft-vandijk-dnsop-ds-digest-verbatim-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:		draft-vandijk-dnsop-ds-digest-verbatim
Revision:	00
Title:		The VERBATIM Digest Algorithm for DS records
Document date:	2020-09-25
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vandijk-dnsop-ds-digest-verbatim/
Html:           https://www.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.html
Htmlized:       https://tools.ietf.org/html/draft-vandijk-dnsop-ds-digest-verbatim-00

Abstract:
   The VERBATIM DS Digest is defined as a direct copy of the input data
   without any hashing.

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: Brian Dickson <[email-masked]>
Date: Fri, 25 Sep 2020 11:05:50 -0700

> 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

---

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

>   The VERBATIM DS Digest is defined as a direct copy of the input data

I could see a use of publishing a DNSKEY at the parent in a DS record
that could be used for encrypted connections towards child nameservers.

But we talked about this within the context of your other proposals,
and the view of a number of people and some large operators was that
this encryption is a per-nameserver thing, and not a per-zone thing.

Another item not covered here we talked about before, is that child
data published in the parent MUST have cryptographic confirmation at
the child. Or else parents can coerce child data.

It seems the setup of this record is geared towards a generic mechanism
of "child publishes stuff at the parent" which muddles the clear child
vs parent zone divider we have now. It would need a very strong use
case, but the other use case offered is "might be handy in the future".
While I agree that DNS infrastructure updates have been extremely slow,
I do think in recent years it has been much better and is still
improving. So I am less concerned about anything taking 5 years again.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 25 Sep 2020 23:27:59 +0200

Hello Paul,

> that could be used for encrypted connections towards child nameservers.

Me too! :-)

> this encryption is a per-nameserver thing, and not a per-zone thing.

Lacking defined use cases and alternative proposals, I'm still
considering the possible future where we have one method for each of
those focuses, with different tradeoffs.

> the child. Or else parents can coerce child data.

Yes, I'm aware! I wanted to keep the -00 simple to first test for
appetite in the WG.

One of the DOTPIN co-authors brought up your 'child confirmation' idea
for both drafts I posted this week, and in both cases, that seems to be
an addition that could easily work. For this draft, in CDS or CDNSKEY;
for the other draft, either by mandating 'some form of it' for anything
that allocates out of the reserved range, or even by specifying right
now 'odd numbers go in the parent, even numbers go in the child, and
content needs to match'.

However, so far it does not look like any of my drafts have gotten
stuck because of -this- so I'm not inclined to put those words in yet.
After adoption seems like plenty of time to discuss this.

> case, but the other use case offered is "might be handy in the future".

Yes - both drafts are 'this may prevent pain later'. I only have
halfbaked ideas for what you could do with 'non-hashed parent-side
publication of child data' (which both drafts provide): DoH URLs,
signed delegation NS sets (which I consider a prime candidate for
'enabling TLSA in child', but that could be done DOTPIN style instead
of either of these drafts), etc.

> improving. So I am less concerned about anything taking 5 years again.

Now if only we could apply that optimism to operator-registry communications :)

Kind regards,