Re: [perpass] A reminder, the Network is the Enemy...

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Mon, 02 December 2013 16:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C5D41AD738 for <>; Mon, 2 Dec 2013 08:56:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KVDe9YZINTgh for <>; Mon, 2 Dec 2013 08:56:37 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 4249E1AD687 for <>; Mon, 2 Dec 2013 08:56:29 -0800 (PST)
Received: from localhost (localhost.localdomain []) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 441AF2C403F; Mon, 2 Dec 2013 08:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([]) by localhost (maihub.ICSI.Berkeley.EDU []) (amavisd-new, port 10024) with LMTP id qXktZd0igrAV; Mon, 2 Dec 2013 08:56:26 -0800 (PST)
Received: from ( []) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8D6442C4038; Mon, 2 Dec 2013 08:56:26 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C25FB1AD-48B6-4CFF-AD4F-3B37F5695EAE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <>
Date: Mon, 2 Dec 2013 08:56:26 -0800
Message-Id: <>
References: <> <>
To: Stephane Bortzmeyer <>
X-Mailer: Apple Mail (2.1510)
Cc: perpass <>, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [perpass] A reminder, the Network is the Enemy...
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2013 16:56:39 -0000

On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer <> wrote:

> On Wed, Nov 20, 2013 at 12:42:53PM -0800,
> Nicholas Weaver <> wrote 
> a message of 70 lines which said:
> You mention DNSSEC twice, as a solution against some man-on-the-side
> attacks (injecting false DNS answers).
> The Schneier paper
> <>
> 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:

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 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‎ ).

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,                full of sound and fury,
510-666-2903                                 .signifying nothing