Re: [Add] Participation

[Rob Sayre <[e-mail]>]

On Sun, Sep 1, 2019 at 2:40 PM Dave Lawrence <[e-mail]> wrote:
> This is not to say protocol attacks never happen.  We're aware of some
> insignificant rare cases of them in the wild.  It is also possible
> that there are more targeted DNS attacks of which the DNS community is
> not generally cognizant, thanks to the ephemeral nature of caches.

Thank you for the thoughtful response. I agree that DNSSEC adoption rates
may not signal a flaw in DNSSEC itself. My hypothesis is that lack of TLS
or equivalent may be hampering a fair evaluation.

In the quote above, who is the "we" in "We're aware"? And what are the
"insignificant rare cases"?

thanks,
Rob

On Sun, Sep 1, 2019 at 2:40 PM Dave Lawrence <[e-mail]> wrote:

> Rob Sayre writes:
> > After 14 years or so, I think DNSSEC adoption rates speak for themselves.
>
> They do, but not in the way you're implying.  Car manufacturers didn't
> want to install seat belts either.  People also aren't naturally
> inclined to buy insurance for all of the various risks they are
> exposed to.
>
> As you are well aware, adding security to a previously insecure system
> inevitably makes the system more difficult to manage and use, whether
> we're talking about Internet protocols or physical world things like
> adding a lock to a door that never had one.  This not only slows down
> the bad guys but also creates a burden for legitimate use.  It might
> be a very minor burden that clearly offsets the risks, such as
> regularly carrying your house key, or it could balloon into a major
> problem, such as when the key is lost.  (Boy do I have a story about
> that.)
>
> DNSSEC is much the same way, but the hazard ratio for not having
> DNSSEC versus having it hasn't yet risen enough, in most
> organizations' calculus, to warrant signing their zones.  In fact,
> they could see the ratio as under 1.0 -- that is, that having signed
> zones is in some ways more risky than not having them.  This is not a
> completely irrational position to take.
>
> Not only does DNSSEC put several additional burdens on both clients
> and servers alike -- CPU, memory and network traffic to varying
> degrees -- but, like losing a key, an administrative failure means
> being locked out.  What's worse, unlike the physical lock situation,
> people who weren't even trying to use a key can get in.  This leads to
> situations like Comcast being widely accused of censoring access to
> NASA.  Because of Comcast's diligence in checking the answers in the
> signed nasa.gov zone, there was an incident where their customers
> could not access the NASA site while the majority of people who did
> not use a validating resolver had no problems at all. Comcast took the
> heat for it in the popular consciousness, which is a bit of
> disincentive for resolver operators.
>
> As for the risks that DNSSEC is trying to mitigate, there's very
> little evidence of cache poisoning via DNS protocol attacks happening
> in practice that would make DNS operators alert to guarding against
> it, certainly many fewer than the pre-seatbelt auto accident death
> rate.  Some known DNS hijacking wouldn't even be thwarted by DNSSEC,
> such as social engineering of a registrar to get registry delegation
> information updated.  That seems to still be the easiest way to mount
> an attack that involves incorrect DNS information.
>
> This is not to say protocol attacks never happen.  We're aware of some
> insignificant rare cases of them in the wild.  It is also possible
> that there are more targeted DNS attacks of which the DNS community is
> not generally cognizant, thanks to the ephemeral nature of caches.
> Imagine, for example, a spear phishing attack that managed to poison
> the cache of a company CEO just long enough for credentials to be
> stolen via a spoofed web site.   30 seconds later there could well be
> no lingering indication that the hostname ever had the wrong address.
> DNSSEC would block this type of threat, but without ready visibility
> into it being exploited there's less motivation for trying to stop it.
>
> The slow pace of adoption of DNSSEC is thus not an indictment of
> DNSSEC itself.  It reflects our essential human nature in managing
> security of all forms.  There's a reason English has the idiom "close
> the barn door after the horse has bolted", and I bet most other
> languages have one of similar meaning.
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>