> Nicholas Weaver <mailto:nwea...@icsi.berkeley.edu> > Sunday, March 15, 2015 4:44 AM >> On Mar 13, 2015, at 7:59 PM, Paul Vixie <p...@redbarn.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
