Re: [dbound] draft-brotman-rdbd

[Stephen Farrell <[e-mail]>]

Hiya,

On 01/04/2019 11:46, Brian Dickson wrote:
> 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".)

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>