Re: [dbound] RDBD Questions

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 23 July 2019 04:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 92FA912004F for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 21:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie
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 0YrKbFjUVlAh for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 21:52:32 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0849E12004E for <dbound@ietf.org>; Mon, 22 Jul 2019 21:52:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 682FCBE51; Tue, 23 Jul 2019 05:52:29 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4QaLsaW2I3R; Tue, 23 Jul 2019 05:52:27 +0100 (IST)
Received: from [31.133.147.102] (dhcp-9366.meeting.ietf.org [31.133.147.102]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BE935BE3E; Tue, 23 Jul 2019 05:52:19 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1563857547; bh=GvrRVmftbkjL4h1rSILTSKiCaM5UM+5X7dqs+RLz9zY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VYZN4idSsDUAKgCIIlkhueiPjEWK0MmMs/dHM1Bu0yVfXBgmTcq1c6TbEUTMFQ/i0 YUY1O4oGlXqIGFD+1gmXp742AqZX89es9DRU9wO3PJ4FKWvUZ5zunZdqjiSqq7uuZp bnuRN7+l/u3WBvDGlVHhx5LCa6SqVrntL8JFkObg=
To: Andrew Sullivan <ajs@anvilwalrusden.com>, dbound@ietf.org
References: <e90bf1c1071b4255841c6b99bd668cb8@COPDCEX19.cable.comcast.com> <75544bed-e393-b9f6-04c4-00164169f5ea@cs.tcd.ie> <20190722225736.4nz4xziuogtvpapo@mx4.yitter.info>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <45d41a2d-1bd2-4562-38fb-6a6c3c9fe4aa@cs.tcd.ie>
Date: Tue, 23 Jul 2019 05:52:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190722225736.4nz4xziuogtvpapo@mx4.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Kkpn8SDWLVJrQu155dmXQropGkO6YJgWN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/usKZSWq2m8L5WOOkySAiORooHQQ>
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: Tue, 23 Jul 2019 04:52:36 -0000

Hiya,

Thanks for the comments, responses below...

On 22/07/2019 23:57, Andrew Sullivan wrote:
> 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.

True.

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

Well, we're trying to be agnostic as to the semantics of
what the relationship is. The logic being that if we get
the mechanism right, additional tags can be allocated later
when specific semantics are in play. So I'm not sure if
describing that as a policy relationship is quite right.

> 
> 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 :) )

I'll re-read those and try steal as and when seems wise:-)

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

Yeah, that's fair. I think we could lose that statement.

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

See above wrt "policy" and semantics.

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

I'm pretty sure I disagree with you there, though I may be
wrong, and/or it could be our text is confusing. What we
meant by uni-directional was that just because example.ie
claims to be related to example.de doesn't mean that
example.de necessarily makes the same declaration. (It can
of course, but might not.)

Whether some consumer of this information really needs to
check that both sides make commensurate declarations is, I
think, dependent on the semantics of the relationship,
which, again, we want to avoid for now.

> 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.  
I suspect anything with pointers can cause loops, but sure,
whenever we're closer to done, this could be handled.

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

Fair enough. Will take a look at it.

> 
> Hope these comments are useful.

They are thanks,
S.


> 
> A
>