Hi, I'm taking the liberty of forwarding the following off the IETF perpass list as Nicholas' analysis matches my own intuition. Stephane Bortzmeyer asked on the same list:
> Very convincing reasoning. But I would feel better if it were actually > tested in a lab with common resolvers. Any volunteer here? I figure this list is a better place for volunteers for this sort of thing than perpass. So, anyone volunteering? :) Regards, -drc Begin forwarded message: > From: Nicholas Weaver <[email protected]> > Subject: Re: [perpass] A reminder, the Network is the Enemy... > Date: December 2, 2013 at 8:56:26 AM PST > To: Stephane Bortzmeyer <[email protected]> > Cc: perpass <[email protected]>, Nicholas Weaver <[email protected]> > > On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer <[email protected]> wrote: > >> On Wed, Nov 20, 2013 at 12:42:53PM -0800, >> Nicholas Weaver <[email protected]> wrote a message of 70 lines >> which said: >> >>> http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/ >> >> You mention DNSSEC twice, as a solution against some man-on-the-side >> attacks (injecting false DNS answers). >> >> The Schneier paper >> <https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html> >> about QUANTUM mentions packet injection but not the DNS. We don't know >> if the NSA does DNS poisoning (but we may assume they - and other >> actors - do it). > > We can bet they do: Its the easiest way (and just about the only way) to > privilege escalate a man on the side to a MITM, which is needed to use things > like a fake cert for SSL decryption. > > A full MITM on a backbone link is a very dangerous thing to install, because > failures get noticed and its also far easier to get the friendly ISP to > install something that is "just a tap", while installing a full MITM closer > to the victim may often be very difficult or downright impossible to do > without getting caught. > >> However, if the attacker is the NSA, we have to take into account the >> possibility that they can sign data with the root's private key, which >> is under US management. Therefore, is DNSSEC still useful? > > Actually spoofing DNSSEC replies even with knowledge of the root key is going > to be difficult... > > Simply put, the attacker is going to need to create a fake path of trust or > an insecure delegation. So, eg, assuming the target is: > > target.example.com > > and the attacker only has a copy of the root key. > > > They are going to have to create a fake NSEC for .com, wait for a query for > .com to go to the root (to enable the fake NSEC record), and then wait until > the victim queries for victim.example.com or the victim does another query > back to the root, which makes getting caught far more likely. > > And since .com and other TLDs support DNSSEC, you could hardcode "there must > be DS record from . for these TLDs", this wouldn't work. (An alternative > would be a fake DS, and then fake EVERY reply from .com with new RRSIGs... > And for that, you have a timing problem because your injector may not know > the answer TO inject!) > > And at the same time, its still packet injection (and therefore still > detectable, see http://conferences.npl.co.uk/satin/papers/satin2012-Duan.pdf > ). > > > So although its possible that the root ZSK gets compromised by the NSA, its > something that I'd not only consider rather unlikely, but something that even > if they did, it would be something they wouldn't want to use, especially now > that packet injection IS on everybody's radar and if they got caught, the > own-goal damage against US interests (so much of DNSSEC on the authority side > has been driven by DHS) would be huge. > > > -- > Nicholas Weaver it is a tale, told by an idiot, > [email protected] full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
