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

From: Nicholas Weaver <[email-masked]>
Date: Mon, 2 Dec 2013 08:56:26 -0800

On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer <[email-masked]> wrote:

> On Wed, Nov 20, 2013 at 12:42:53PM -0800,
> Nicholas Weaver <[email-masked]> 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-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 15:46:52 +0100

On Mon, Dec 02, 2013 at 08:56:26AM -0800,
 Nicholas Weaver <[email-masked]> wrote 

> is going to be difficult...

Very convincing reasoning. But I would feel better if it were actually
tested in a lab with common resolvers. Any volunteer here?

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Dec 2013 12:12:26 -0800

On Dec 3, 2013, at 6:46 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> Nicholas Weaver <[email-masked]> wrote a message of 112 lines which said:

I think a better target for that question would be [email-masked] :)

Regards,
-drc

---

From: Matthäus Wander <[email-masked]>
Date: Thu, 05 Dec 2013 11:09:43 +0100

> Actually spoofing DNSSEC replies even with knowledge of the root key is going to be difficult...

If we assume the attacker can get the private root KSK from an US-based
corp, then we should also assume they can get the private root ZSK from
another US-based corp. As the owner of the root ZSK also owns the keys
for .com, the attack becomes much easier.

Regards,
Matt

-- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Dec 2013 16:18:52 +0100

> for .com, the attack becomes much easier.

let's start a list of juristictions which we believe are NOT compromised
and dangerous.  i will start it off by submitting andorra.

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Dec 2013 10:27:29 -0500

> and dangerous.  i will start it off by submitting andorra.

Finding the one person you can trust is a bad strategy. Andorra is
considerably less likely to stand up to NSA bullying attempts than
Microsoft is. Microsoft certainly has more lawyers.

A better approach is to design the system so that it takes a defection by
more than one party. Instead of relying on just the ICANN root KSK require
a TLD to be signed by three out of five trusted national cryptolabs.

-- 
Website: http://hallambaker.com/

---

From: David Conrad <[email-masked]>
Date: Fri, 6 Dec 2013 08:12:12 -0800

On Dec 5, 2013, at 7:27 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> A better approach is to design the system so that it takes a defection by more than one party. Instead of relying on just the ICANN root KSK require a TLD to be signed by three out of five trusted national cryptolabs.

Trusted by whom? E.g., trusted like NIST now? (No disrespect of folks at NIST intended: just observing some may no longer view them as trustable)

I personally believe a better approach is to make the operation of the system extremely public and documented such that it doesn't matter who is involved since the risk would be too high that attempts at compromise would be observed. This is what ICANN tried to do with the root KSK (one can argue whether they succeeded). 

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Dec 2013 19:01:23 -0500

On Fri, Dec 6, 2013 at 11:12 AM, David Conrad <[email-masked]> wrote:

> > A better approach is to design the system so that it takes a defection
> by more than one party. Instead of relying on just the ICANN root KSK
> require a TLD to be signed by three out of five trusted national cryptolabs.
>
> Trusted by whom? E.g., trusted like NIST now? (No disrespect of folks at
> NIST intended: just observing some may no longer view them as trustable)
>

I mean trusted in the technical sense of relying on them (albeit to a
qualified degree).

And it is important to note that trusted does not mean the same thing as
trustworthy, a point I raised at one of the early trusted computing group
efforts (only Microsoft seemed to take note or maybe they came up with the
understanding independently).

If you have a three out of five scheme one should choose five labs that are
very likely to collude. The UK, US, Australia, Canada and New Zealand would
not be a very good choice. The UK, France, Russia, India and Brazil would
be a rather better one. Of maybe you would want to have the EFF or the like
in there (if they could set up a secure facility and maintain it at
acceptable cost).

> I personally believe a better approach is to make the operation of the
> system extremely public and documented such that it doesn't matter who is
> involved since the risk would be too high that attempts at compromise would
> be observed. This is what ICANN tried to do with the root KSK (one can
> argue whether they succeeded).
>

These do not need to be exclusive, nor was that my proposal. I would expect
any national cryptolab to follow the established industry practices.

---

From: Russ Mundy <[email-masked]>
Date: Thu, 5 Dec 2013 10:35:30 -0500

> for .com, the attack becomes much easier.

If we (as the IETF) make an assumption that the DNSSEC private key(s) are "available" to some "unauthorized entity" (govt or otherwise) because a significant part of a particular operation is located in a particular geographic region then we need to also make a similar assumption for any/all Certification Authorities' root private key(s) since the underlying cryptographic technology widely used by TLS is basically the same.  The DigiNotar attack, though not geographically related, clearly illustrates that very bad things can happen when an "unauthorized entity" is able to have access to and use of root private keys for a CA.

I've seen some references on this list saying (essentially) that it is a valid assumption that an "attacker" ("unauthorized entity" might be a better term) can get or already has the DNS root (& maybe .com) private key.  Although I do not believe that this is a valid assumption, I do assert that if we (as the IETF) decide to make such an assumption relative to DNS/DNSSEC then we must make the same assumptions about "unauthorized entities" being able to access private root key(s) for any/all CAs.  I'm not sure how the IETF would somehow factor geopolitical boundaries into defining protocol assumptions, I suspect that any useful results would probably take longer than it's taken to design, redesign, redesign and begin deployment of DNSSEC :-).

OTOH, if there is real interest and need to change and/or enhance the security operations &/or protocols for the DNS or CA realms, having concrete proposals (such as  draft-grothoff-iesg-special-use-p2p-names-00.txt) is much more useful than trying to reach agreement on assumptions like the above (& other earlier email assertions).

Russ

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 00:54:04 -0500

On Thu, Dec 5, 2013 at 10:35 AM, Russ Mundy <[email-masked]> wrote:

> If we (as the IETF) make an assumption that the DNSSEC private key(s) are
> "available" to some "unauthorized entity" (govt or otherwise) because a
> significant part of a particular operation is located in a particular
> geographic region then we need to also make a similar assumption for
> any/all Certification Authorities' root private key(s) since the underlying
> cryptographic technology widely used by TLS is basically the same.  The
> DigiNotar attack, though not geographically related, clearly illustrates
> that very bad things can happen when an "unauthorized entity" is able to
> have access to and use of root private keys for a CA.
>

I agree with respect to covert attacks. Yes there is a risk in both cases
and the right control is to establish a very high probability of detection
so that it becomes an overt attack.

What is unique in the case of the DNSSEC is that there is only one root and
thus a government can perform a denial of service attack against TLDs.For
example asserting that signing the Cuba or Palestine roots would breach
existing sanctions legislation or passing new legislation.

And such scenarios do not seem at all far fetched to me having watched the
government shutdown.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Dec 2013 09:11:07 +0100

On Thu, Dec 05, 2013 at 10:35:30AM -0500,
 Russ Mundy <[email-masked]> wrote 
 a message of 67 lines which said:

> I've seen some references on this list saying (essentially) that it
> is a valid assumption that an "attacker" ("unauthorized entity"
> might be a better term) can get or already has the DNS root (& maybe
> .com) private key. 

Small fix: I did not say so (the root private key is in an HSM and
presumably, nobody, not even the NSA, can take it out). I said "the
NSA can probably sign arbitrary data with the private key of the
root". In practice, it has the same consequences. But it is a common
mistake when people assert the security of things like domain name
registries. You don't need to hold the private key, you just need the
ability to feed data to the signer and get the result, which is
typically much easier.