[dns-operations] Fwd: [perpass] A reminder, the Network is the Enemy...

[David Conrad]

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 <nweaver at ICSI.Berkeley.EDU>
> Subject: Re: [perpass] A reminder, the Network is the Enemy...
> Date: December 2, 2013 at 8:56:26 AM PST
> To: Stephane Bortzmeyer <bortzmeyer at nic.fr>
> Cc: perpass <perpass at ietf.org>, Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>
> 
> On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> 
>> On Wed, Nov 20, 2013 at 12:42:53PM -0800,
>> Nicholas Weaver <nweaver at icsi.berkeley.edu> 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,
> nweaver at icsi.berkeley.edu                full of sound and fury,
> 510-666-2903                                 .signifying nothing
> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131204/afba007e/attachment.sig>