Re: [dbound] draft-brotman-rdbd

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 01 April 2019 11:42 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 33D5D1200FD for <dbound@ietfa.amsl.com>; Mon, 1 Apr 2019 04:42:44 -0700 (PDT)
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 aZ6jOO85agIa for <dbound@ietfa.amsl.com>; Mon, 1 Apr 2019 04:42:40 -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 A767B120127 for <dbound@ietf.org>; Mon, 1 Apr 2019 04:42:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A0A43BE24; Mon, 1 Apr 2019 12:42:34 +0100 (IST)
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 Aqz9u6hF9WiZ; Mon, 1 Apr 2019 12:42:34 +0100 (IST)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5C398BDCF; Mon, 1 Apr 2019 12:42:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554118954; bh=YNA7eo40SA16odmONZsBZszO8JNHWF5kPIZ6V/e3IaQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=sDp1LH+NYL3OqainRJNAt4CMry/JiuOq7nDmCSMcPRuH+MjpBoGnVnracn5zO+A4z mKxQzV/7S28aOA6JhPND+v/bKJ5qc1c7H+7gCnmAFC+Rr05VG4ZmV2PCHZkPL/FFD2 yHjIWtnO2X2fMOt6fCvSpfFC6j/ihEbFLeF4ZTjQ=
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: dbound@ietf.org, "A. Schulze" <sca@andreasschulze.de>
References: <f6862326-40e1-d804-cefe-e63c79a0534d@andreasschulze.de> <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> <CAH1iCipco+0Wvb1kpZ-S3EQYdsYywZzQo+sEeLikNZjMwMYMgg@mail.gmail.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: <cb41ecd0-c48d-b204-7ab1-f59ff330bda3@cs.tcd.ie>
Date: Mon, 1 Apr 2019 12:42:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAH1iCipco+0Wvb1kpZ-S3EQYdsYywZzQo+sEeLikNZjMwMYMgg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6M5xKf0gFdtblCUdUoXk6NGruuyssEcEU"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/JUZsyeXe1F8HSC2JETxGHa67jHQ>
Subject: Re: [dbound] draft-brotman-rdbd
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, 01 Apr 2019 11:42:52 -0000

Hiya,

On 01/04/2019 11:46, Brian Dickson wrote:
> On Sun, Mar 31, 2019 at 3:57 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
> wrote:
> 
>> On 29/03/2019 17:06, A. Schulze wrote:
>>
>>> And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs may
>> make the signature/validation stuff easier.
>>
>> I'm afraid I don't agree that DNSSEC can be a requirement here. RDBD
>> by itself is not sufficiently compelling to cause a DNSSEC deployment.
>> And DNSSEC is just not sufficiently deployed to make it a requirement.
>>
> 
> I'd like to better understand the rationale for the general/specific
> sentiment.
> 
> I think the disconnect starts with the question about the purpose, or
> alternatively, explicit limitations, of RDBD:
> 
>    - Does the existence of RDBD records change the trust by any actor, any
>    system, any mechanisms, anything?
> 
> 
> If the answer is no, then I don't see the compelling value for RDBD, and
> really have no interest here. Sorry. (However, I also don't think this is
> the case.)
> 
> If the answer is yes, then IMHO, RDBD may REALLY need to check its
> assumptions regarding DNS cache poisoning.
> (Hint: if DNS were a pre-industrial world map, the cache would be labeled
> "Here there be dragons".)

Fully agree that cache poisoning is a relevant threat for any
application that would use RDBD values read from DNS without
sufficient additional local validation to make a decision.

In my use-case (better counting in surveys) that's not so much
of a deal. I think in Alex's mail use-case, it's also less of
a deal as this is just one of many inputs that would be seen
over time so they'd not be making decisions based on just
seeing one RDBD value one time.

But I do agree that if people publish RDBD records, then
someone will indeed write code to make such decisions no matter
what we tell them to (not;-) do.

> The strongest defense known against DNS cache poisoning, AFAIK, is DNSSEC.
> Any others are at most weak hacks to marginally increase entropy.

True.

> Using any other type of crypto keys stored in DNS, without protecting those
> with DNSSEC, is also vulnerable to cache poisoning. They are just DNS
> records.

Sure. And the draft needs to document that (probably better
than it currently does - more/better text is welcome).

> So, without using DNSSEC, successful cache poisoning can subvert RDBD,
> whether or not any other signature stuff is used:
> 
>    - The attacker only needs to subvert the DNS entries for all the RDBD
>    records , i.e base RDBD record(s) with signatures, and corresponding
>    RDBDKEY record(s).
>       - This is addressed as a security concern currently in the draft, but
>       understates/underestimates the risk or effort, IMHO
> significantly (or even
>       fatally).
>    - Since this is a DNS cache attack against both the key and signature,
>    it does not require the RDBDKEY (as published on the authority
>    server(s)) to be compromised.
> 
> In contrast, use of DNSSEC makes any other signature redundant/moot, at
> best; it makes key management problematic on top of DNSSEC key management,
> at worst.

Not quite (but see below).

> Here's why: DNSSEC signing a record which contains a domain name meets all
> the requirements of the RDBD.
> Using the ZSK as the RDDBKEY devolves the RDBD record trivially:
> 
>    - All the stuff after the relating domain name in the current draft, is
>    basically an RRSIG (with a few fields elided).
> 
> The gist of the above is: if you have deployed DNSSEC for a zone, the RDBD
> RRTYPE does not need to consist of anything more than a domain name (FQDN).

Not quite. The above is true if DNSSEC is deployed for both
zones involved in an RDBD relationship. If only one of them
is signed, then it's not exactly the same, and the additional
RDBD-signature can offer some value if the relating domain's
zone is DNSSEC-signed.

Again, I don't want to overstate that value, but I reckon it
has non-zero value. It is entirely valid to wonder if the
complexity of that additional signature is or is not worthwhile.
I guess, but cannot prove, that it is worthwhile to define
RDBD-signatures as an optional thing, perhaps esp. if the
related domain is the kind of thing setup by some marketing
person for example.

If neither zone is signed, then we're in the same position
as most DKIM deployments. People do seem to have derived some
value from that, despite the lack of a requirement for DNSSEC.

> This is not to say that an RDBD does not have value; in fact, I believe
> there is significant value here.
> That value can be maximized by streamlining the encoding, re-using the
> signature work from DNSSEC, and keeping the RDBD RRTYPE easy to understand
> and use.

I would entirely agree if DNSSEC deployment were further along.
However, that is not the case.

As it happens, for the dozen or so small zones I manage, I have
deployed DNSSEC and it's been pretty easy once we figured out
how to automate re-signing and getting DS records to the parent.
(I've yet to do CDS/CDNSKEY stuff but that should improve it
some when the parent registry supports it.)

But I have also spoken to quite a few people who say they cannot
deploy DNSSEC or who think DNSSEC doesn't offer them enough to
be worth the costs.

> 
> Rationale, explanation, & disclaimer regarding cache poisoning weakness:
> 
> I've made assertions previously in a variety of venues, about the level of
> effort required for cache poisoning being very low generally.
> At some point I should probably write up the details, so it is clear to the
> IETF crowd doing DNS (previously this has been shared at DNS-OARC but not
> by me in the DNS-related WGs).
> The root source of the weakness has been published elsewhere by others ,
> and presented by them in (IIRC) the security area general session. See:
> 
>  Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous",
> Technical Report 13-03, March 2013, <
> http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>;.
> 
> My claim is that that report underestimates the degree of vulnerability of
> caches to such attacks.
> 
> If the authors of RDBD would like a private detailed explanation, I'd be
> happy to share it.
> I am reluctant to publicly share the details just now, as I believe this
> would require appropriate responsible disclosure with abundant time to fix
> the underlying issues.
> In particular, it is really critical to have necessary fixes deployed in
> nearly all the authority operators' and recursive operators' networks,
> prior to any details being published openly.
> 
> (You may not agree with the above, without me explaining the particulars.
> My suspicion is you will probably agree with the above after I explain it.
> Please contact me off-list for the explanation.)

I don't need to be convinced that caches can be poisoned;-(

> 
> Here's my opinion generally of what RDBD should be composed of:
> 
>    - DNSSEC signed RDBD records consisting of only the related-domain names.

If we dropped the RDBD-signature, and a zone has DNSSEC that'd be
almost true, with just the rdbd-tag field being there in addition.
(See below for more on that rdbd-tag.)

>    - Matching mutual claims of relationships should be a requirement (or at
>    least a SHOULD with explanation of the security risks of relying on
>    unmatched claims).

I'd argue that the point above conflicts with the point below.
And I also don't get what's wrong with unidirectional assertions.
Can someone explain? (I do understand that some people want
assertions in both zones, which is entirely possible, but I
don't get the downside of doing that via two unidirectional
assertions. Requiring changes in two zones also seems to be
more brittle in general.)

>    - Ability of a domain to explicitly exclude all relationships (thus
>    preventing any matches). Completely unambiguous encoding is required for
>    this.

Yep, we'll include that in -02 for sure, it's a good idea.
I think assigning an rdbd-tag value for that might work.

I'm less sure how to handle the other thing people seemed to
want which was to explicitly list other names that are not
related. (Mostly as that could be a big list.) I guess one
could simply have a bunch of RDBD RR values each of which says
that there's no relationship, but I don't know when the numbers
there would become a problem. (Anyone able to say? Would 100
RR values be an issue? 10^3? 10^4?)

>    - Optional URI record(s) pointing at some well-defined semantic blob(s)
>    for what the trust implies, for whoever the consumer of RDBD is. (Probably
>    out of scope for the core RDBD spec.)

In -01 we added the rdbd-tag for that, with tag value 0
meaning "some unspecified relationship." Other tag values
can be assigned later, with whatever semantics are right
for those. One of those could I think do what you want
here, e.g., rdbd-tag==N could mean to go look for a URI
RR value in some well-defined place to find a well-defined
blob of JSON perhaps.) I'd also note that such additional
specifications could be where one makes a statement that
DNSSEC is required - that needn't necessarily be done for
all uses of RDBD.

Cheers,
S.

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