Re: [DNSOP] [art] [dbound] Related Domains By DNS (RDBD) Draft

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 27 February 2019 19:58 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E6B681310AC; Wed, 27 Feb 2019 11:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_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 GDkOAbrJN8ca; Wed, 27 Feb 2019 11:58:51 -0800 (PST)
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 6ADF6128766; Wed, 27 Feb 2019 11:58:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5933ABE38; Wed, 27 Feb 2019 19:58:49 +0000 (GMT)
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 jqtky8thXEOZ; Wed, 27 Feb 2019 19:58:47 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80798BE2C; Wed, 27 Feb 2019 19:58:47 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551297527; bh=EfZWAJM7HFVHBPoaRb05+zRBWNTOy/zK5XJEIzU5JUo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fMa9NfeHWiBKbj5uFNhymt3HGQu0i8qBfacvIIJwDR/Doeu4ImatVH7Jw8GGrtwVI Y8IRUJxdBSXQ0Dx9CV+tn8hwPub8LqlGVGGmpkogDixo7uTo5nygi5THfXNMY6nHEO mq53UOc196s774xH8yBOAKHgMwzOuvXRAXTo91s0=
To: Ted Lemon <mellon@fugue.com>
Cc: "art@ietf.org" <art@ietf.org>, "Brotman, Alexander" <Alexander_Brotman@comcast.com>, Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org" <dnsop@ietf.org>, "dbound@ietf.org" <dbound@ietf.org>
References: <5de9ba1c3ae34edb9c7f39e0e9c3b143@PACDCEX19.cable.comcast.com> <alpine.LRH.2.21.1902270920580.8896@bofh.nohats.ca> <alpine.LRH.2.21.1902271037500.21061@bofh.nohats.ca> <8cbf0062-35c6-a8bd-e809-c6a5e9ce16c8@cs.tcd.ie> <CF78A911-D3BD-47C0-B25D-CCD359FFCC5B@fugue.com>
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: <249a56b6-7bf6-d1e3-2639-0f2d8043aa3e@cs.tcd.ie>
Date: Wed, 27 Feb 2019 19:58:46 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CF78A911-D3BD-47C0-B25D-CCD359FFCC5B@fugue.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="b3qZP7poFqdgO1rwluqh5E64zA1Mjz3vT"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Q0dfR3WE-E-FvUtBQG_QGMDNy0A>
Subject: Re: [DNSOP] [art] [dbound] Related Domains By DNS (RDBD) Draft
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: Wed, 27 Feb 2019 19:58:55 -0000

Answering two for the price of one...

On 27/02/2019 17:26, John R. Levine wrote:>> new signatures), I myself
only copped on that this could
>> be of some use where the primary has DNSSEC but where the
>> secondary doesn't, which is maybe interesting.
>
> In that case, the primary can just publish pointers to the secondaries,
> and we're done.
>
> The DKIM-like signatures have an odd model where the primary has enough
> control over its DNS to publish the validation key, and enough to give
> the secondaries signed records for their names they can publish that
> point back to that key, but not enough just to publish the secondaries'
> names directly.  I don't get it.

That could work, but'd mean the primary having to store
all the records and an extra lookup if even if you had the
public key cached. I believe the former could be an issue
if there are many secondaries, at least according to one
chat I had with someone involved with many domains (which
I'm not). I think the design in our -00 is a bit better
than that, but not hugely better and it's ok we can disagree
about it - if this goes somewhere there'll be plenty of
time to thrash it out as we go.

On 27/02/2019 18:38, Ted Lemon wrote:
> On Feb 27, 2019, at 10:57 AM, Stephen Farrell 
> <stephen.farrell@cs.tcd.ie> wrote:
>> Yep. After both domains have DNSSEC, then this could all be 
>> simpler. Before they do, there may be value in the sigs though see 
>> John's simplification suggestion at [1].
> 
> If they don’t have DNSSEC, what’s the point of saying the domains
> are related anyway?   What are the security properties of such an 
> assertion when the content of the zones can’t be validated?

The point of making the assertion would be in the eye of the
beholder. The level of confidence one might have in such an
assertion (without DNSSEC) should of course be lower. But we
do work without DNSSEC for almost everything today so I'm
not convinced "no DNSSEC" => can't be done here. (And again,
the use-cases we've discussed are not high-security ones.)

FWIW, I am a fan of DNSSEC, deploy it for domains I control,
and do consider that despite it's gnarliness it provides
real benefits. But I don't believe we can seriously require
it as a pre-requisite for almost anything today, and nor do
I believe that our proposal, if it goes ahead would by itself
cause people to deploy DNSSEC. So ISTM that making DNSSEC a
MUST-use isn't the right approach in this case.

Cheers,
S.


> 
> 
> 
> _______________________________________________ art mailing list 
> art@ietf.org https://www.ietf.org/mailman/listinfo/art
>