Re: [dbound] draft-brotman-rdbd

[Brian Dickson <[e-mail]>]

On Sun, Mar 31, 2019 at 3:57 PM Stephen Farrell <[e-mail]>
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".)

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

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

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.

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


Here's my opinion generally of what RDBD should be composed of:

   - DNSSEC signed RDBD records consisting of only the related-domain names.
   - 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).
   - Ability of a domain to explicitly exclude all relationships (thus
   preventing any matches). Completely unambiguous encoding is required for
   this.
   - 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.)

Brian