[dbound] Related Domains By DNS (RDBD) Draft

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 08 March 2019 22:22 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 D52CE1277C9 for <dbound@ietfa.amsl.com>; Fri, 8 Mar 2019 14:22:04 -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 S2PsR0Gy4P0v for <dbound@ietfa.amsl.com>; Fri, 8 Mar 2019 14:22:02 -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 AA0CA12716C for <dbound@ietf.org>; Fri, 8 Mar 2019 14:22:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7590BE50; Fri, 8 Mar 2019 22:21:55 +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 7IFU5LPCKYua; Fri, 8 Mar 2019 22:21:52 +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 940ADBE38; Fri, 8 Mar 2019 22:21:52 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552083712; bh=qM0GDf/VwfyCGwcbgZwns++FajXt9gAU7BTTq+V2SK0=; h=To:References:From:Subject:Date:In-Reply-To:From; b=lyeTWhtiJJos5yTU24stYTD88aRuIfYeNhq56NjBivqx2xcSGgb+Ts/+VUC7j3cK7 D+dW8V+aEnWRlVl7UX1vpMW7Ukh9lhX6MONh2IZGlSuibtFG2Lj9IJFKkP0jMai7dx 6i3Nb/kpbHEc8g9F/BZU+W1wZuIziGnwD5KmJkwk=
To: Samuel Weiler <weiler@csail.mit.edu>, dbound@ietf.org
References: <20190227172143.10303200F57CE0@ary.local> <1FFA1977E97DE99C390869DA@PSB> <alpine.OSX.2.21.1902272038320.3336@ary.local> <49A2FC767B5A7146F39456B9@PSB> <A4E532F7-484E-4605-8D77-8E0A20A15014@gmail.com> <alpine.OSX.2.20.1903081516350.70761@macbook-air-8.local>
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: <87a520c1-194a-ffd7-b58f-fea6e549d090@cs.tcd.ie>
Date: Fri, 8 Mar 2019 22:21:51 +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: <alpine.OSX.2.20.1903081516350.70761@macbook-air-8.local>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G0rXrtHlyT5Rbwgp2kg09lXSfPiIRTQGu"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/nUtc2MP8RwTvrNqDvuf_ndrEE3c>
Subject: [dbound] Related Domains By DNS (RDBD) Draft
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: Fri, 08 Mar 2019 22:22:05 -0000

Hi Sam,

(Fixing the subject a bit - there's no DNAME here:-)

On 08/03/2019 20:30, Samuel Weiler wrote:
> On Fri, 1 Mar 2019, Suzanne Woolf wrote:
> 
>> My memories of DBOUND are not reliable but I do recall a distinct
>> sense that people thought they were talking about "the same thing" and
>> repeatedly discovering that maybe they weren’t.
>>
>> Accordingly, I’d like to see an example or two of how you’d expect an
>> application to use the kind of connection between domains established
>> by the RDBD mechanism.
> 
> +1.

We added some text on that in -01, in the intro. See the top
of page 3. Wasn't that clear enough?

That text is deliberately terse and not intended to outline
a complete set of use-cases.

My take is that part of the reason DBOUND failed was an
attempt to be all things to all parties. I think repeating
such an attempt with RDBD would lead to the same failure.
I at least, (and I think Alex too), are determined to not
have this fail for that particular reason. (It may fail for
others of course:-)

Just because we're using this list does not mean we have
to repeat the collective mistakes to which we variously
previously contributed using this list:-)

As a consequence I also think it is perfectly fine if RDBD
suffices only for one or a couple of purposes. If it does,
and usefully enough that it gets deployed, and doesn't do
damage otherwise, the rest can look after themselves later.

So even if there are additional credible use-cases, (and
I guess there are) I don't really care or want to discuss
those myself as doing so is likely to lead to the same
failure outcome as occurred with DBOUND.

It is also of course fine to disagree that our chosen bit
of the design space is the place to stick a stake in the
ground. In that case, I'd be happy to discuss other folks'
stakes and locations for 'em once I see their I-D.

Meanwhile, we'd like to discuss this particular design (and
not all possible others) and find out if it looks good enough
for all the people who'd need to, to do the work required to
get such RRs published and used.

> Reading back through the end-of-DBOUND discussions from 2016, I'm having
> these same thoughts.
> 
> Digging into two details:
> 
> I don't understand the value added by publishing new keys - and signing
> with a new signature format - when there's no evident way to bootstrap
> trust in those keys.  Could you explain (again) the value being added? 
> (I see value from using DNSSEC, but if we insist on DNSSEC, we don't
> need these other pieces.)

That comes from the history of DKIM I guess. It turns out that
unsigned keys in DNS demonstrably can provide some value if they
get (re-)used.

In this case, a signature indicates that the relating-domain (or
private-key-holder) was involved in the declaration that a
relationship exists. (Or that an active attack is ongoing, which
is ok, there's still value as not all transactions are under
active attack all the time. See RFC 7435.)

That said, I fully accept that the added value of the (now
optional) signatures isn't too high. See my earlier discussion
with John L.

> The DBOUND problem statement draft covered a number of "use cases that
> seem intuitively similar [but] actually aren't" (quoting Suzanne). Even
> so, it made a general recommendation in the security considerations
> section: "In general, positive assertions about another name should
> never be accepted without querying the other name for agreement."  I'm
> surprised to not see that reflected in this draft. Indeed, the
> discussion here suggests that this is an explicit non-requirement.  

We're not starting from the DBOUND problem statement here. If you
were to ask me would I do that, my answer would be "no thanks,
that didn't work before."

> So I
> want to know more about the use case(s) you're tackling 

Sure. Happy to take any questions on the text we added.

> and why checking
> the symmetry of assertions is not necessary.

If you want symmetry, then just do this trick twice. I don't see
any issue with that.

I also don't think all relationship are symmetric, so it just
seems to make sense to support asymmetry too.

Cheers,
S.



> 
> https://www.ietf.org/archive/id/draft-sullivan-dbound-problem-statement-02.txt
> 
> 
> -- Sam