Subject: Re: [dbound] draft-brotman-rdbd

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 09:11:22 +0100

Hiya,

On 01/04/2019 04:51, Scott Kitterman wrote:
> On Monday, April 01, 2019 03:44:46 AM Stephen Farrell wrote:
>> On 01/04/2019 03:38, John R. Levine wrote:
>>> I suppose that if there were some very high value application that
>>> depended on rdbd records there might be more of an incentive to use DNS
>>> attacks to fake them, but it all seems like a lot of extra work for
>>> utterly speculative benefits.
>>
>> Questioning the efficacy of rdbd signatures is reasonable but not
>> at all the same as a claim to not understand 'em.
>>
>> I agree that the efficacy of these signatures isn't a slam dunk.
>> The draft says as much. I'd be happy to improve the explanation
>> in the text wrt that.
>>
>> But the signatures are optional. So if I'm wrong that they're
>> useful, then that's ok, you'll be right and they'll not be used.
>> Equally, if OTOH but unexpectedly, I'm not wrong, then there'll
>> be a method for signing defined as part of the spec.
>>
>> What's wrong with that?
> 
> It adds some significant complexity to the design.

True.

> If the crypto bits have significant utility, then baking the needed protocol 
> elements for smooth key rollover (e.g. for DKIM you use a new selector and 
> leave both the old and new keys live for $TIME to allow everything that was in 
> process to be received and validated before the old key is removed).  Are 
> multiple RDBD and RDBDKEY records allowed per domain?

Yes.

> If not, particularly due to cache misalignment, a smooth key rollover will be 
> very hard.
> 
> Multiple records per domain would also allow for algorithm agility (publish 
> both RSA and Ed25519 for transition as needed).
> 
> Libraries implementing RDBD would need more dependencies and be more complex 
> to deploy.
> 
> My suggestion would be to think hard if it's really needed and if so, then 
> make it a MUST.  If not, take it out.  

Also a reasonable position.

> It can be added easily enough later, 
> right?

Not sure TBH. I think adding rdbd-signatures later would mean
defining another RRTYPE, which is about as much work as this.
I've no idea how that'd affect deployment either.

> 
> I do think the explanation could be clearer.  I was following along with John 
> Levine's argument pretty well.  It took me several scans of the draft to 
> realize that the signature (RBDB record) is published by the relating domain 
> and the public key (RDBDKEY record) is published by the related domain.  Once 
> I realized that, it made sense.  A signed record, to the extent you can't 
> spoof both domains simultaneously or nearly so, would give added confidence 
> that the related domain agrees that that relationship is valid and not just 
> examp1e.com claiming to be related to example.com.
> 
> As a more general comment, RFC 8301 is the reference for the minimum key size 
> of 1024 bits (RFC 6346 is 512).  Also, it might be worth looking at RFC 8463 
> (which added Ed25519 to DKIM) to see if there's guidance on putting Ed25519 
> public keys in DNS that can be reused.

Will try clarify those issues, thanks.

> Personally, I think I like the crypto bit, but if it's in, I'd like to see it 
> be a MUST.  

Fair enough.

Other inputs on this topic appreciated! I guess the choices are:

1. take out rdbd-signatures entirely, as per John L I guess
2. leave rdbd-signatures optional, as per -01
3. make rdbd-signatures mandatory, as per Scott K

(I consider those are independent of DNSSEC as we're signing
across and not downwards with rdbd-signagures.)

> Also, do we really need RSA?  There are plenty of Ed25519 
> implementations available.  Personally, I think it's simpler to deal with (and 
> the public keys are way smaller, which is nice for DNS).

True, but I'd argue to keep RSA for now at least as e.g.
openssl's command line tools don't yet have ed25519 (for
internal API reasons, so not clear when that'll be fixed).
RSA could get dropped along the way I guess if things
change sufficiently before this draft is done.

Cheers,
S.

> Scott K
> 
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 1 Apr 2019 03:46:23 -0700

On Sun, Mar 31, 2019 at 3:57 PM Stephen Farrell <[email-masked]>
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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 12:42:32 +0100

Hiya,

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

True.

> with DNSSEC, is also vulnerable to cache poisoning. They are just DNS

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

> best; it makes key management problematic on top of DNSSEC key management,

Not quite (but see below).

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

> signature work from DNSSEC, and keeping the RDBD RRTYPE easy to understand

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.

> Please contact me off-list for the explanation.)

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

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

>    least a SHOULD with explanation of the security risks of relying on

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

>    preventing any matches). Completely unambiguous encoding is required for

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

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

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2019 12:18:59 -0400

>sufficient additional local validation to make a decision.

Could you give some concrete examples of additional local validation,
other than DNSSEC?

As far as I can tell nobody does anything like that for DKIM keys.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 18:17:07 +0100

Hiya,

> Could you give some concrete examples of additional local validation,

Sure. In my use-case (surveys), I keep the keys used from one
scan to the next, so e.g. I have about 4 scans of Irish and
other SMTP servers taken over the last 18 months and can see
when some keys do or don't change. Were RDBD deployed, I'd do
the same for those keys, if they got used. (To be clear, I've
not been doing that for DKIM keys to date, but for TLS and SSH
server keys.)

> As far as I can tell nobody does anything like that for DKIM keys.

I don't know if anyone does, but wouldn't be surprised if
some anti-abuse folks reacted to a mail provider switching
from one long-lived key selector to a new one not seen
anywhere before. (But I'm speculating there, others who do
that kind of thing for real would need to confirm that or
not.)

Cheers,
S.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 1 Apr 2019 11:18:43 -0700

> deploy DNSSEC or who think DNSSEC doesn't offer them enough to

So, just so I understand it, you are saying the deployment of DNSSEC on the
authoritative side is the problem/issue, in terms of scale of deployment,
and in terms of costs and ease of user, reliability, etc?
Do you see other areas where DNSSEC deployment is problematic? I suspect
resolver validation needs some boosting, but IMHO, once authority use
becomes more common, that should sort itself out.

My observation is that what you are stating (about the authoritative
DNSSEC) is mostly anecdotal.
I'd prefer to be informed by statistical information, if it is available.
Or, I'd like to at least provide information (i.e. existence proofs) on
reliability, ease of use, cost, and scale, that might help make the case
that DNSSEC deployment issues are mostly about communication issues,
awareness, and motivation.

E.g. There are large-scale operators of managed DNS services who offer
DNSSEC at little or no extra cost, trivially easy use, proven reliability,
etc.
This would seem to partly contradict the deployment thing, if the only
thing they need to do is turn it on. (Estimated coverage: 60% of zones.)
There are certainly cases where DNSSEC is incompatible (at least
currently), such as CDNs, geo-ip, potential ANAME (and provider-specific
ANAME-like things currently in use).
But aside from those, the barriers to entry have been lowered considerably,
at least in the managed DNS space.

Brian

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2019 16:39:42 -0400

> I don't know if anyone does, but wouldn't be surprised if some 
> anti-abuse folks reacted to a mail provider switching from one 
> long-lived key selector to a new one not seen anywhere before. (But I'm 
> speculating there, others who do that kind of thing for real would need 
> to confirm that or not.)

That's more likely to be taken as a positive signal, that they finally got 
their key rotation working.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 22:25:32 +0100

Hiya,

> becomes more common, that should sort itself out.

Seems a bit of a side-issue for this discussion but happy to
discuss off-list. (I do think launching into each of our ideas
as to what's good or bad about DNSSEC would be distracting
here and more on-topic e.g. for dnsop and not this list.)

> DNSSEC) is mostly anecdotal.

Sadly not.

[1] seems to show that <1% of .com 2lds are signed and barely
more than 1% of .net 2lds.

[2] provides a bit of a basis for limited optimism but still
shows around about 1 million signed 2lds despite some ccTLDs
offering small financial incentives to those who sign.

A 2018 peer-reviewed paper [3] ([4] for non-paywall) including
Roland Van Rijswijk-Deij as an author (whom I at least would
trust on this) says that "The security extensions to the DNS
(DNSSEC) currently cover approximately 3% of all domains
worldwide." (Which I guess can be consistent with the above
given depth inside signed zones.)

FWIW my general position is that we ought be making DNSSEC
easier to use where we can, and we should encourage deployment
but we cannot really make it a dependency for pretty much any
new protocol, or that new protocol will be extremely constrained
in where it can be deployed. (The optional RDBD signature
mechanism is consistent with that, in that it kinda tries to
spread the benefits of DNSSEC to an RR from the related domain,
if the relating domain is DNSSEC signed but the related domain
is not.)

Cheers,
S.

[1] https://www.statdns.com/
[2] https://stats.dnssec-tools.org/
[3] https://ieeexplore.ieee.org/abstract/document/8406223/
[4]
https://research.tue.nl/en/publications/economic-incentives-on-dnssec-deployment-time-to-move-from-quanti