Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed

From: Zack Weinberg <[email-masked]>
Date: Mon, 03 Oct 2011 13:06:30 -0700

On 2011-09-30 11:49 PM, Matt McCutchen wrote:
>> A DANE client that ignores DNSSEC validation under any circumstances
>> -- note that in this scenario, it doesn't get any TLSA records back at
>> all! -- will not defend against this attack; but a client that treats
>> DNSSEC "bogus" or "stripped" states as a hard failure, regardless of
>> TLSA contents, will defend.
>
> To simplify matters a bit, note that RFC 4033 "bogus" includes what you
> are calling "stripped".

Thanks for the correction.  I think I was trying to remember the RFC 
4033 distinction between "insecure" (parent zone signed, child zone 
attestably unsigned) and "indeterminate" (no trust anchor at all).  At 
some point clients will have to start treating "indeterminate" as a hard 
fail to prevent a network MITM from downgrading them by completely 
stripping DNSSEC, but I think that's out of scope for DANE; it belongs 
in a 'how to consume DNSSEC properly' document.

>>> Again, I believe the new proposal adds one step: "if you received a type 2
>>> response, make sure it was covered with DNSSEC". That's the same
>>> number of steps as "if you received any response, make sure it was
>>> covered with DNSSEC".
>>
>> I hope I have demonstrated that this is inadequate.
>
> You and Paul are arguing past each other.  Paul is assuming a validating
> resolver that doesn't even give you a response unless it is "secure" or
> "verified insecure"; in that case, you're already protected from
> tampering with signed TLSA records.

Ah, but no! The attacker needs to be a little more sophisticated in this 
case, but it's still doable.  They leave DNSSEC intact for the A record, 
block the TLSA response entirely, and intercept traffic to the 
legitimate server by messing with the *routing*.  A client that falls 
back to legacy PKIX behavior under these conditions loses the protection 
of a cert-type 0/1 restriction.

Basically, the only time it is safe for a DANE client to downgrade to 
legacy PKIX behavior on a signed zone is if it *actually receives* a 
valid NSEC(n) response for the TLSA record query.

The details of "doesn't even give you a response" matter here, of course 
- maybe this can be made secure with a resolver library that behaves as 
you describe, if its error codes are sufficiently detailed.  But it 
still requires the application to consider DNSSEC state ahead of 
processing any TLSA records that are received.  And therefore it is 
*operationally* simpler to process DNSSEC state once and for all before 
even looking at the TLSA records.

I want to repeat that my concern here is strictly implementational.  I 
agree that

> If you get verified-insecure
> records of usage 0 or 1, you do not gain or lose any *security* by
> processing them

(emphasis mine) but I think that "MUST ignore all verified-insecure TLSA 
records, regardless of their contents" is sufficiently more likely to be 
*implemented correctly* that it is worthwhile, even though it sacrifices 
a use case on the server end (deploying DANE restrictions without being 
ready to do DNSSEC yet).

zw

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Oct 2011 16:16:05 -0400

On Mon, Oct 03, 2011 at 01:06:30PM -0700, Zack Weinberg wrote:

> At some point clients will have to start treating "indeterminate" as
> a hard fail to prevent a network MITM from downgrading them by
> completely stripping DNSSEC

No, they won't.  If you have a trust anchor and you get back an answer
that you can't validate, you fail the validation.  That means that if
you have a trust anchor for the root and the root's answer doesn't
validate, you fail starting there.  Once you have the first validated
answer, you can follow the chain so long as there are no islands.  You
only have to worry about the indeterminate case when you encounter an
island for which you don't have a trust anchor -- in which case you
couldn't validate anyway.

If any of the answers from your valid trust anchor are tampered with,
you will be able to tell, and you can fail at that point.

Many people worry about this "stripping" problem, but it isn't
possible.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 03 Oct 2011 13:22:04 -0700

On 2011-10-03 1:16 PM, Andrew Sullivan wrote:
 > validate, you fail starting there.

It is precisely this that may not be operationally feasible at present. 
  A client with a configured trust anchor for the root zone may still be 
in a circumstance where it can't get DNSSEC information for any zone, 
for a reason that does not imply a security problem (e.g. an obsolete 
recursive resolver that's dropping DNSSEC data on the floor).

> You only have to worry about the indeterminate case when you encounter an

Given that the root has now been signed, I'm not sure whether this case 
can occur anymore - please clarify.

zw

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Oct 2011 16:32:11 -0400

On Mon, Oct 03, 2011 at 01:22:04PM -0700, Zack Weinberg wrote:

> It is precisely this that may not be operationally feasible at
> present.  A client with a configured trust anchor for the root zone
> may still be in a circumstance where it can't get DNSSEC information
> for any zone, for a reason that does not imply a security problem
> (e.g. an obsolete recursive resolver that's dropping DNSSEC data on
> the floor).

If it's "dropping DNSSEC data on the floor", the DNS response will
fail validation and be bogus.  If, however, it responds with the DO
bit not set, you have a different situation.  That does seem to be a
case where you could have an attacker on network; you would have to
decide whether you'd accept a response without DO.  

> Given that the root has now been signed, I'm not sure whether this
> case can occur anymore - please clarify.

Sure it can.  If you don't send your DNSKEY or DS data to your parent,
then the trust chain doesn't go across the zone cut and you're an
island.  The DNS is a distributed database.  Everyone needs to do
their part, or the chains break.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 11:58:33 +1100

> recursive resolver that's dropping DNSSEC data on the floor).

Then pick a different recursive server / complain to the operator
of the recursive server.  EDNS is 12 years old (1999).  DO is 10
years old (2001).  DNSSEC bis is 6 years old (2005). There really
is no excuse to not pass DNSSEC records along in 2011.  They don't
have to validate, though it helps if they do.

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 3 Oct 2011 19:38:09 -0700

> have to validate, though it helps if they do.

The root was only signed last year (2010) and even now very few
network clients actually look for and validate DNSSEC records -- so as
much as I would *like* to agree with your position, I suspect it'll be
another several years before it's realistic.

zw

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 14:28:36 +1100

In message <[email-masked]>
> another several years before it's realistic.

While signing the root was a significant milestone it really as
nothing to do with whether DNSSEC records will be passed on recursive
servers.  You need to look at when DNSSEC aware recursive servers
shipped as they can pass on the records with or without trust anchors
being configured.

For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and
BIND 9.6.0 (NSEC3 support Dec 2008).  As far as BIND is concerned
all supported versions support NSEC3 and DNSSECbis.

Mark

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 03 Oct 2011 21:06:21 -0700

> all supported versions support NSEC3 and DNSSECbis.

Until people start consuming DNSSEC data at the edge, nobody in the 
middle has any serious incentive to make sure it works; so I think
your estimate of the state of the *installed base* of *everything that 
has to pass DNS traffic along* is over-optimistic.

Nicholas Weaver had actual numbers which, as I recall, said it would be 
possible to start doing that consuming now, but *not* to treat DNSSEC 
outages as evidence of malicious tampering.

zw

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 15:48:51 +1100

In message <[email-masked]>, Zack Weinberg writes:
> > While signing the root was a significant milestone it really as > > nothing to do with whether DNSSEC records will be passed on recursive

In most cases there are only two middle boxes to worry about.  The
ISP's resolver and the CPE device.  The resolver, if it is DNSSEC
aware, is already dealing with any upstream issues.  That leaves
CPE devices which should be field updatable in most cases.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 03 Oct 2011 22:42:37 -0700

On Mon, 2011-10-03 at 13:06 -0700, Zack Weinberg wrote:
> block the TLSA response entirely, [...]

> valid NSEC(n) response for the TLSA record query.

Yes, yes, I meant to say that the server authentication code fails
closed unless it gets a response from the resolver, which in turn does
not return a response unless it is "secure" or "verified insecure".
Clearly, if one wants the security of DNSSEC, one has to... fully
enforce DNSSEC.  These distinctions are all beside the point of the
thread.

> processing any TLSA records that are received.

No, if the resolver library exposes "failed to get a secure or verified
insecure response" as an error code in the same right as "network is
unreachable", since the outcome needs to be "fail closed" either way (a
momentary network blip should not compromise the security any more than
MITM tampering), the code would likely just check for an error and not
specifically for DNSSEC state.

> And therefore it is 

As above, it depends on the library, though you are probably right for
many clients.

> a use case on the server end (deploying DANE restrictions without being 

This is just speculation against speculation.  I am personally -0.5 to
putting a MUST that is not in fact a requirement of the security model.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 03 Oct 2011 22:55:44 -0700

On Mon, 2011-10-03 at 13:06 -0700, Zack Weinberg wrote:
> stripping DNSSEC,

I think Andrew tried to clarify this, but I will try again:

The occurrence of the "indeterminate" state is purely a function of your
configuration.  If you have a trust anchor for "." and the MITM
completely strips DNSSEC, that is bogus, /not/ indeterminate.

The above is the DNSSEC model.  One can conceive of various bodges to
work on existing networks, but since most of them would completely give
away the security in a theoretical sense, I don't find it very useful to
discuss the security of DANE in the presence of such bodges.  It's more
sensible to build DANE cleanly on the DNSSEC model and simply let the
bodger beware.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 08:58:51 -0400

DNSSEC deployment can and will be blocked by a government level
adversary. Since that is what we are facing here it seems pointless to
tie the spec to one platform we know the adversary can and will mount
a denial attack on.

Russia is not pushing GOST because they care about obscure crypto
algorithms. They are pushing GOST because back in the 17th century the
Tzar murdered the aristocracy and enslaved the peasants and the place
has been an authoritarian sink-hole ever since. It is about control.

That does not mean that DNSSEC is useless, it just means that the role
of DNSSEC is going to be limited to authenticating exchange of
information in the free world where use is permitted. But that is OK
because we have other techniques, tools and protocols for crossing the
digital curtain.

Adam's proposal to put the chain in the cert is the way to do key
distribution on the basis of the DNSSEC hierarchy. Well, modulo the
fact that it works much better with legacy browsers if the token can
be put into an OCSP token.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 09:02:27 -0400

If an enterprise is using DNSSEC to secure its internal network, the
root of trust for the devices in that network SHOULD and MUST flow
from a key that is controlled by the enterprise and not by ICANN.

That is a very basic principle of security that is understood by
pretty much anyone who is likely to be a DNSSEC early adopter.

nsa.gov is not going to chain from the ICANN root.

In fact the intra-governmental squabbling in the US federal govt, was
so great that we could not even get them all to agree on one root for
the federal govt. Hence the invention of the bridge CA.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2011 09:30:51 -0400 (EDT)

> CPE devices which should be field updatable in most cases.

Those can be circumvented using a caching resolver directly.

However, the ISP case and CPE case leave out the "mangling port 53" case.
That could be a firewall near the CPE or ISP, and is actually a bigger
issue.

Then there is the brief DNS blackhole during signon

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2011 09:40:12 -0400 (EDT)

On Tue, 4 Oct 2011, Phillip Hallam-Baker wrote:

> distribution on the basis of the DNSSEC hierarchy.

Sadly, it required a leap of faith of having connected first without having
been under attack, so while a "nice to have" it does not actually solve the
security issue.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Oct 2011 11:47:19 -0400

> from a key that is controlled by the enterprise and not by ICANN.

<no_hats>
That's a fairly strong (and broad) statement, for which I do not think I see much evidence (although I don't know that many enterprises that are signing / validating internal stuff)  -- from other folk who have seen enterprise deployments are you seeing enterprises use the IANA root or their own? 

I'm interested -- if DANE folk don't have much visibility here, maybe I'll shuffle this off to the dnssec-deployment list (or DNSOP / EXT / etc)...

</no-hats>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Oct 2011 12:11:15 -0400

On Tue, Oct 04, 2011 at 11:47:19AM -0400, Warren Kumari wrote:

> That's a fairly strong (and broad) statement, for which I do not
> think I see much evidence (although I don't know that many
> enterprises that are signing / validating internal stuff) -- from
> other folk who have seen enterprise deployments are you seeing
> enterprises use the IANA root or their own?

There was a lot of talk a couple years ago about TARs (Trust Anchor
Repositories) and how they'd be managed.  That all seemed to have
dried up and blown away, and if people really wanted to use private
keys to anchor some part of the namespace, I expect we'd be hearing a
lot of discussion about how to manage such keys and so on.

Nevertheless, there appears to be a consensus among implementers that
"closest key wins" is a legitimate approach for managing the trust
path, so that if you have a key for . and you have a key for
example.com, you use the latter (and by option only the latter) for
validating www.example.com.  Given that these are shipping
implementations, I presume there's demand.  I find it hard to believe
that, in the face of stone-age key management tools, the experience is
going to be satisfying.  But I guess some people want to do this.

There's an additional issue here: if you seriously believe that the
root key path is vulnerable, then presumably (1) you think there's a
similar possible problem from the traditional X.509 infrastructure,
and (2) you think that the root DNS is also a serious vulnerability.
In environments I have actually experienced, these beliefs are the
sort of things that people say a lot, but when faced with the terrific
inconvenience of living with the consequences they don't actually do
it.  There are environments where the network people are capable
enough and well-funded enough to implement this sort of thing, but I
have pretty grave doubts that they're common.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2011 12:25:52 -0400 (EDT)

> going to be satisfying.  But I guess some people want to do this.

not so much "want" but "need". If you need to internet to resolve your
internal names because of a missing DNSSEC chain element, you just broke
all internal resolving when there is a WAN outage. Can't be good for job
security :P

Then there is the "internal only domains", that have no reference in
external DNS, so you are forced to configure a key and forwarder
anyway or else they will end up as "bogus".

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 12:45:09 -0400

> I'm interested -- if DANE folk don't have much visibility here, maybe I'll shuffle this off to the dnssec-deployment list (or DNSOP / EXT / etc)...

Well I have run up many private CAs for just that reason. Most of the
'600' roots that the EFF claim to exist are actually enterprise
intermediate certs that were created for exactly that purpose. Take
those out and the number of issuing points falls bellow 50.

It is pretty easy to fix the DNSSEC scheme. Each enterprise merely
cross signs the root and publishes it in their own zone.

ICANN even provides a CSR for this express purpose.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Oct 2011 13:27:10 -0400

> anyway or else they will end up as "bogus".

Another way to put this is that DNSSEC exposes you to yet another way
in which your delusion of a single namespace with private chunks
doesn't work ;-) 

There actually was a draft a number of years ago about doing DNSSEC in
split-brain environments, but it failed because of the immediate
problem of admitting that split-brain is a major piece of
slightly-filthy technology on which everyone depends.  MIF is busy
jumping up and down on that electrified rail, however, so maybe the
log jam will break.

None of this gets us any closer to closure on the main topic, though,
I think.  I actually cannot fathom why anyone would go to the trouble
of using TLSA without DNSSEC, so I fail to see the value in making the
decision tree for an implementation more complicated and the attack
surface bigger for what seems like a pretty negligible benefit.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 04 Oct 2011 21:03:33 -0700

> tie the spec to one platform we know the adversary can and will mount

How does this relate to my message?  Did you mean to reply to a
different subthread?

> be put into an OCSP token.

Right, in terms of reducing dependencies on third-party servers,
stapling positive assertions to TLS is the way to go.  It's just more
work to implement than directly querying DNSSEC like I did in my
prototype.  (As Paul pointed out, stapling doesn't work for restrictive
assertions.)

-- 
Matt

---

From: [email-masked]
Date: Wed, 5 Oct 2011 09:28:35 +0000

> I'm interested -- if DANE folk don't have much visibility here, maybe I'll shuffle this off to the dnssec-deployment list (or DNSOP / EXT / etc)...

	I see many, many organizations that enrobe their corporate networks w/ corporate
	crypto.  (VPN's come to mind) 
	Not all corporate (or say military) networks are going to be connected, full time,
	all the time, to the ICANN visible root (see the ICANN report on alternate roots,
	esp in corporate networks .. its been a fact of life for decades)

	So i beleive that it would be short sighted to presume that -everyone- is part of
	the always on, always connected, Internet with an ICANN root.

	In my discussions about DNSSEC over the years, the stance I have always taken is
	that the ICANN root key is the -least- trustworthy key in my keyring, since so 
	very few people actually have a business relationship with ICANN.  I trust my
	corpoate generated crypto much more - since they pay me.  And I trust my ISP more,
	since I pay them.  ICANN's root key is the last key I trust.  Afterall, they are
	the "last resort"... Right?

/bill