Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

[Paul Vixie <[e-mail]>]

> Nicholas Weaver <mailto:[e-mail]>
> Sunday, March 15, 2015 4:44 AM
>> On Mar 13, 2015, at 7:59 PM, Paul Vixie <[e-mail]> wrote:
>
>>> 	Nicholas Weaver	Saturday, March 14, 2015 5:07 AM
>>>
>>>> ...
>>>>
>>>> Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good.
>> several of us jumped for joy in 2008 when kaminsky showed rdns poisoning to be a trivial exercise, because it finally provided justification for what was at that time 12 years of apparently-wasted effort on DNSSEC.
>
> But it didn't justify DNSSEC, even at the time.

no, of course not. dnssec was well justified by the need for new
dnssec-aware applications such as DANE. all we got from kaminsky was a
whip to frighten the crowds with.
>
> Between actually adding in a bit more entropy in the request through 0x20 and port randomization, and more importantly cleaning up the glue policy for recursive resolvers (which Unbound did), you close the door on off-path attackers: both making races harder AND eliminating the "race until win" property.

i wish this were so. but 0x20 didn't add enough bits on average-sized
names, and furthermore, a lot of RDNS servers are behind NAT. (CGN is a
reality, in japan.) NAT's source port derandomization is as dangerous as
we thought. far too many RDNS servers were never patches, or were
patched but NAT'ed.

>> so we'll keep pushing the crap system we have, uphill all the way, noone loving it, and almost everyone in fact hating it. we've now spent more calendar- and person-years on DNSSEC than was spent on the entire IPv4 protocol suite (including DNS itself) as of 1996 when the DNSSEC effort began. ugly, ugly, ugly.
>
> At which point is it sunk cost fallacy?

it always has been. we needed end-to-end authentication, because of
bullshit like SOPA, and ad-insertion, and DNS Changer. the DNS
resolution path looks like raw meat for the BBQ's of every ISP and many
ASP's and governments and criminals and oh my. but DNSSEC was the wrong
answer, architecturally, because it tried to secure the middle of the
data path rather than the ends, and no dnssec-aware endpoint can get
DNSSEC if they are behind a non-dnssec-aware RDNS or CPE. it's been an
inarguable clusterfsck for the last ten years. we are so far into the
sunk cost fallacy on DNSSEC that we can't even see or remember our
starting conditions any more.

> "DNS is insecure, live with it" may be the best answer.  Why keep throwing good effort after bad?

it's not, though, the best answer. we have to secure the DNS resolution
path. what's in doubt is whether DNSSEC can do this, or if it can,
whether it's the best way to have done this.
>
>
> It certainly is a hell of a lot better than the DOS attack that is recursive resolver validation which provides almost no meaningful security gain.

don't get bent about dnssec as an amplifier. TXT is also a fine
amplifier. but in many DDoS victim data paths, the bottleneck is defined
in terms of number of packets processed, not the number of bits
processed, so a non-amplifying reflector is still quite valuable to
attackers. even an attenuator at the bit level is quite valuable. (an
attenuator at the packet level is not valuable to attackers, which is
why RRL uses SLIP=2 as a default.)

in other words we had to, and still have to, solve the reflector problem
-- with or without DNSSEC. andrews/eastlake "dns cookies" will do that.
and once we've done that, "DNSSEC as a DoS vector" will be just another
dead meme.
>
> If I was Comcast, after the HBO DNSSEC mess-up, on top of previous mess-ups where Comcast inevitably gets the blame, I'd be really really tempted to turn OFF DNSSEC validation.  It has failed.

i know what you mean and i'd face the same temptation. i wonder if there
has ever been a validation failure in the comcast resolver complex that
wasn't due to a keying/signing cockup by the domain holder -- that is,
if comcast has to have negative trust anchors to protect its validation
investment, what's the upside? could they defend their users just as
well by not running validation at all, so that keying/signing problems
don't have to be managed by the comcast NOC?

what matters for DNSSEC is the end-to-end case. as long as comcast is
running DNSSEC-aware resolvers, they don't need to validate anything in
order to make DNSSEC applications like DANE workable for their
customers. and i'd rather see them turn off validation than see negative
trust anchors added to the specification.

-- 
Paul Vixie