Re: [DNSOP] Tell me about tree walks

Paul Vixie <paul@redbarn.org> Thu, 12 November 2020 05:10 UTC

Return-Path: <vixie@redbarn.org>
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 BA4B93A13F6 for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2020 21:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 IzXimB_vlhL2 for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2020 21:10:10 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4426F3A13F5 for <dnsop@ietf.org>; Wed, 11 Nov 2020 21:10:08 -0800 (PST)
Received: by family.redbarn.org (Postfix, from userid 716) id 165F2C3F03; Thu, 12 Nov 2020 05:10:06 +0000 (UTC)
Date: Thu, 12 Nov 2020 05:10:06 +0000
From: Paul Vixie <paul@redbarn.org>
To: Tony Finch <dot@dotat.at>
Cc: John Levine <johnl@taugh.com>, dnsop@ietf.org
Message-ID: <20201112051006.4tcrq4cyu6ltkpio@family.redbarn.org>
References: <20201111181423.7B1A9262936D@ary.qy> <alpine.DEB.2.20.2011112128510.17264@grey.csi.cam.ac.uk> <20201111220822.34bia6nagfnimwuw@family.redbarn.org> <alpine.DEB.2.20.2011112224170.17166@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.2011112224170.17166@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6YWId7A-GLu1hwMAKCxi8_liS_4>
Subject: Re: [DNSOP] Tell me about tree walks
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: Thu, 12 Nov 2020 05:10:13 -0000

On Wed, Nov 11, 2020 at 10:38:12PM +0000, Tony Finch wrote:
> Paul Vixie <paul@redbarn.org> wrote:
> >
> > i'd like to be able to filter inbound traffic based on who paid the
> > money for a domain, who got that money, or whether either of them
> > wishes to remain anonymous.
> 
> The crucial difference is that CAA/DMARC are consensual: the publisher and
> the checker both want to use the protocol to stop baddies doing bad
> things. But your situation is more adversarial: you (the checker) want to
> find out if the publisher is good or bad.

did you see army of darkness? do you remember what Ash said about good/bad?

> There's not much chance of success trying to use a protocol designed for
> friendlies in situations of distrust, let alone active combat!

i guess i'll go another couple of rounds with this, even if it means
answering what i haven't said after somebody ignores what i did say.

forget about why i want it, if that helps. or, if you're willing, imagine
a world where registrars who want to be associated with the domains they
sell clearly mark those domains with their identifier, and others, not so.

* * *

here's what i know. there are registrars who are proud of their business
practices and policies, who despise their race-to-the-bottom competitors
as much as anybody could. but they have no way to differentiate themselves
since the third parties who are satisfied by a takedown never tell anybody.

the ietf has offered these registrars no in-band at-scale on-the-wire method
to demonstrate greater care in their output. i'm not sure why we would
expect an industry to improve itself without metrics supporting
differentiation.

same goes for registrants. if we want differentiated acceptance levels for
new domains based on whether the registrar and registrant are willing to
self-identify to an authentic reputation, we have to make it possible.

if social networks could put new account requests in a delay queue whenever
they can't identify the registrar or registrant, or if e-mail servers
could do likewise with arriving e-mail, then the cream would float to the
top, and everything else could be made to cost more and take longer. right
now reputation is only a bad thing, and accountability is _not_ improving.

but none of that matters for the purpose of extending the protocol. what
matters is just that there is no way for a registrar and/or registrant to
mark their domain with an identity. perhaps for registrants it's just RP?
perhaps for registrars it's a new schema for RP, appearing above the zone
cut or at some cousin name to avoid the DS problem?

i'm not asking that you adopt my economic vision, nor split any bosons.

-- 
Paul Vixie