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

[Paul Wouters <[e-mail]>]

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

> On Thu, Sep 24, 2020 at 10:53 PM Paul Wouters <[e-mail]> wrote:
>
>       [added hrpc to CC: list]
>
>       On Thu, 24 Sep 2020, Peter van Dijk wrote:
>
>       > 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.
>
>       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
>
>       > 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
>
>       _______________________________________________
>       DNSOP mailing list
>       [e-mail]
>       https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
>