Re: [dbound] RDBD Questions

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 22 July 2019 22:57 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658BC1200BA for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 15:57:43 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Fn8QLCqO; dkim=pass (1024-bit key) header.d=yitter.info header.b=GErDLoUl
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 Hfsw2OI__xQ5 for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 15:57:41 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEA21200DE for <dbound@ietf.org>; Mon, 22 Jul 2019 15:57:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 216AABCD30 for <dbound@ietf.org>; Mon, 22 Jul 2019 22:57:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1563836260; bh=FKqfDhfqBYfq39hzsWVbZq42g0ThZj0Xd6pab3PuvsM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Fn8QLCqOAcRSA9nEfwm/lWpZjSt+VrYEfLv+Bu/LKak6anoeTChsO/qmwiSFTr+Pr nye8fE/mw5KWeZkCJU0ZOIHGneNsXm/DrV7MF6c0zkTtvUpQpoLh/pVNFoDd1m5S1Q ZX4yYlgZOoFYulX0MWVldGxHpTrZmM2xfwxjzyr4=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXoqbyZgn08B for <dbound@ietf.org>; Mon, 22 Jul 2019 22:57:38 +0000 (UTC)
Date: Mon, 22 Jul 2019 18:57:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1563836258; bh=FKqfDhfqBYfq39hzsWVbZq42g0ThZj0Xd6pab3PuvsM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GErDLoUl+uYIIBROM/kWLDSZBLaGr9RHCDGFw6FWceYujjthMSOUVfci4ef5MiD8d eZyZVZ8mDpDA6e/DlHisxe/PWH73CVuBmhQ1DHSvhHy+qmAxVc2kSlpkbG21bZIZMP SXn5p/jtZYvvfRwwCEzNfVKgJC+7Huk6jiTlPikY=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20190722225736.4nz4xziuogtvpapo@mx4.yitter.info>
References: <e90bf1c1071b4255841c6b99bd668cb8@COPDCEX19.cable.comcast.com> <75544bed-e393-b9f6-04c4-00164169f5ea@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <75544bed-e393-b9f6-04c4-00164169f5ea@cs.tcd.ie>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/ePq3On0wqDsSYVACUf1MY3jKko4>
Subject: Re: [dbound] RDBD Questions
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 22:57:44 -0000

Hi,

As usual, though I happen to be employed by the Internet Society, I'm
speaking for myself here.

On Mon, Jul 08, 2019 at 05:00:22PM +0100, Stephen Farrell wrote:
> To add to your reading pleasure on I-D cutoff
> day, we've updated the draft [1] as described
> below. Comments welcome as always.

I've read this.  As you might imagine, I rather like what this draft
is trying to do.  I also like the symmetry with the CDNSKEY trick,
though I'm not sure it's going to work.  Thanks for doing this, in any
case, because I'm happy to see someone trying to solve this problem.

One of the things that I think the draft would benefit from is some
terminological distinctions that I think have long been missing.  I
think this shows up right in the introduction:

   Determining relationships between registered domains can be one of
   the more difficult investigations on the Internet.

In some sense, of course, this is plainly false.  "Is an ancestor of"
and "is a descendent of", in the strict graph-theoretic sense of the
meaning of "relationship", is easy to decide.  All other
relationships, in the DNS, are _from the point of view of the DNS_,
not that interesting.

The problem the draft is trying to address, however, is _not_ a DNS
relationhip.  Instead, it's an attempt to affirm that there is a
_policy_ relationship between two domains.  This is reasonably clear
if you look at the use cases in the bullet list.

I think that some of the conceptial material might be lifted from
https://tools.ietf.org/html/draft-sullivan-dbound-problem-statement-02
or maybe
https://www.ietf.org/archive/id/draft-sullivan-domain-policy-authority-02.txt
or https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02
(I tried, fruitlessly, more than once, as you can see :) )

One of the potential snags I see in here is a possible trap involving
the nature of domain names.  It's contained in this observation: "RDBD
is intended to declare or disavow a relationship between registered
domains, not individual hostnames."  The problem is, basically, that
inside the DNS there's actually no way to specify that distinction
without querying for a bunch of SOA records, because every valid
domain name is also trivially a valid owner name for an A or AAAA
record and also a valid point for there to be a delegation.  Indeed, a
domain can also be a hostname easily.  (It might be worthwhile having
a look at https://tools.ietf.org/html/rfc8499 to see whether the
terminology aligns really, though I suspect so.  The real problem is
the ambiguity in the relationship between domain names and hostnames.)

I totally do not understand this claim:

   RDBD relationships are uni-directional.  If bi-directional
   relationships exist, then both domains can publish RDBD RRs and
   optionally sign those.

The relationships in question are necessarily policy relationships.
In that sense, it is simply impossible for the relationship to be
unidirectional, because it is a way of the "setting" side of making
claims that are somehow supposed to be satisfied by the "setted" side
of the relationship.  Moreover, whenever you have a domain that
appears to be a relating-domain that makes an assertion about a
putatively related-domain, it seems to me that you need to check at
the related-domain to see whether the putatively related-domain
actually in fact has a repudiating record.

It strikes me that the lookup loop problem in 6.3 happens precisely
because of the unidirectionality of the definition.  That is, if you
had a bidirectional requirement, then it would be effectively
impossible to have the chained loop described because the
bidirectionality would cut that off.  This would also avoid adding the
somewhat arbitrary limit of how many lookups one ought to do.  (I
observe also that this SHOULD in section 6.3 doesn't really comport
with the 2119 meaning of SHOULD, though I'm not one of the bossypants
people about these uses.)

Hope these comments are useful.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com