Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Aug 2010 23:36:08 -0400

On 7/30/2010 8:54 PM, Andrew Sullivan wrote:
> On Fri, Jul 30, 2010 at 12:16:48PM -0400, Phillip Hallam-Baker wrote:
>> One issue missing from the charter is the question of use of DNSSEC in
>> applications.
> 
> It certainly is not missing from the charter in the sense that it is
> our problem, and we need to tackle it.
> 
> We are narrowly focussed on issues of the DNS protocol.  Nothing about
> how applications get to DNS results, &c, are our problem.  Indeed,
> they're not even the problem of the _area_ we are in: they're more
> likely to be APP than INT.
> 

I agree that it's not a protocol issue. I am however concerned that
functions like getaddrinfo() provide no way to require that the resolve
use DNSSEC to validate the answers returned or for that matter when the
answers are returned the TTL for each answer is not given. You might not
care about validating google.com but you definitely would about your
bank's website.

Danny

> All of that said, I encourage people who think there are
> application-level issues here to submit individual drafts.  If there
> were three or four such drafts that talked about application-level
> interaction with DNSSEC, it might strike people who are inclined to
> try to organize IETF work (i.e. all of us, right?!) that we could take
> steps to co-ordinate that work (i.e. form a working group).  Of
> course, we already have some efforts in that direction.  But the key
> thing, under the current process rules, is to have a manifest
> community of interested parties.  Let's see those internet drafts!  I
> am sure that, though this sort of work be out of our charter, your
> chairs will not object to the occasional announcement about such
> drafts.  When it gets heavy, we'll ask for a separate IETF mail list.
> Alternatively, ask for one (perhaps M. Sury wull suggest that you
> should use the one he is setting up.)
> 
> Best,
> 
> A
>

---

From: Florian Weimer <[email-masked]>
Date: Tue, 03 Aug 2010 15:22:02 +0000

> One issue missing from the charter is the question of use of DNSSEC in

The only way an application can "use" DNSSEC is to refuse to work with
insecure (provably unsigned) responses.  What would be the benefit of
that?

Putting data into DNS which can be used for cryptographic operations
and policy decisions at other protocol layers looks rather useful to
me, but this has nothing to do with DNSSEC at all.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Joe Abley <[email-masked]>
Date: Tue, 3 Aug 2010 12:12:50 -0400

On 2010-08-03, at 11:22, Florian Weimer wrote:

> insecure (provably unsigned) responses.

Why is that the only way?

Joe

---

From: Florian Weimer <[email-masked]>
Date: Tue, 03 Aug 2010 16:12:33 +0000

* Paul Wouters:

> The federated DNS approach has a big advantadge. Trust moves from
> larger to smaller groups, you can override it at any point for your
> personal 1 trust anchor, [...]

This only applies as long as your trust decision is somehow related to
the name.  I fear that this model only looks more attractive than
established alternatives because we lack real-world experience and
typical failure scenarios.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 03 Aug 2010 12:16:02 -0400

>insecure (provably unsigned) responses.  What would be the benefit of

Consider for a moment the email system.  It seems to me that it might be a good idea for an MTA to refuse to deliver email to an MTA  or mail store for which the MX record is bogus.  And I would consider that a benefit. Or refusing to accept email from a site where the signed PTR record doesn't point back to a signed and consistent A record.

But mail is one of the few applications where the routing information is stored in the DNS.  Other automated (non-interactive) applications that depend on NAPTR or SRV records may also be good candidates for this type of automatic block. 

>me, but this has nothing to do with DNSSEC at all.

Putting data into the DNS which can be used for cryptographic operations looks like a very bad idea to me for at least the reasons noted by Basil.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 03 Aug 2010 16:18:43 +0000

> Why is that the only way?

All data which is available with DNSSEC is also available without
DNSSEC.  Without such artifical rejections, any DNS-based protocol
would work equally well with signed and unsigned zones.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 03 Aug 2010 17:57:42 +0100

> would work equally well with signed and unsigned zones.

In practical terms there is a distinction between the application,
the library, the stub resolver, and the recursive nameserver.

Consider a legacy application that calls gethostbyname(), and a
library that supports DNSSEC that attempts a lookup on a name
in a signed zone where the authoritative nameserver concerned
has been compromised and is producing incorrect data (assume
it's signed elsewhere so the key has not been compromised).
My feeling is that it would be useful behaviour if gethostbyname()
returned something other than the incorrect A record.

The things one might choose to upgrade to support DNSSEC to achieve
this allegedly useful result are:
1. Recursive nameserver
2. Stub resolver
3. Library
4. Application

It would seem a pity if it were necessary to upgrade all four of
these to get it.

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Aug 2010 18:34:38 -0400

The reason that I have been so anxious to get DNSSEC deployed is that
there are important security problems that can only be solved through
DNSSEC. That is not one of them.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 3 Aug 2010 16:05:09 -0700

> DNSSEC. That is not one of them.

What important security problems?

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 4 Aug 2010 16:00:44 +0800

----- Original Message ----- 
From: "Joe Abley" <[email-masked]>
To: "Florian Weimer" <[email-masked]>
Cc: "Phillip Hallam-Baker" <[email-masked]>; "namedroppers" <[email-masked]>
Sent: Wednesday, August 04, 2010 12:12 AM
Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications

>> insecure (provably unsigned) responses.

you should give the customers or the applications a choice, dnssec or not.

if you force the customers to use dnssec, they may be unhappy.

for internet banking or business, dnssec is a good choice, but for others, may be not.

> Why is that the only way?

+1

if we force dnssec today, many applications may not work due to a lot of un-enabled dnssec domain names.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 04 Aug 2010 17:35:43 +0900

> DNSSEC. That is not one of them.

There is no important security problem solvable by DNSSEC.

						Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Aug 2010 05:13:15 -0700

On Aug 4, 2010, at 5:07 AM, Phillip Hallam-Baker wrote:

> Preventing a downgrade attack.
> 
> At the moment the biggest hole in SSL is that it is optional and the
> client does not have any in-band method of finding out if it is
> supported.

DNSSEC doesn't help because it suffers from the exact same downgrade attacks.  Thus unless you have UNIVERSAL signing of DNS data, the in-path attacker just downgrades DNSSEC first.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Aug 2010 08:07:48 -0400

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Aug 2010 12:13:20 +0000

> client does not have any in-band method of finding out if it is

Again, this is totally unrelated to DNSSEC.  An application which
prevented downgrade attacks only if it knows that the indicating DNS
resource record was secure (that is, DNSSEC-signed) would be a foolish
thing to implement.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Aug 2010 12:19:44 +0000

* Michael StJohns:

> Consider for a moment the email system.  It seems to me that it
> might be a good idea for an MTA to refuse to deliver email to an MTA
> or mail store for which the MX record is bogus.

"bogus" in what sense?  The DNSSEC sense?  This already happens
automatically in vendor-default DNSSEC configurations.  No protocol or
application changes are required.

> Or refusing to accept email from a site where the signed PTR record
> doesn't point back to a signed and consistent A record.

Seems like a bad idea to me because that would reject tons of
legitimate mail.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Aug 2010 08:28:38 -0400

Again, you are assuming that I am going to only limit my design to the
fragile ICANN infrastructure.

That is not going to be my proposal.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Aug 2010 12:29:12 +0000

> returned something other than the incorrect A record.

When the zone is secure (in the DNSSEC sense) from the point of view
of the resolver, then the legacy application will not receive that A
record.

> It would seem a pity if it were necessary to upgrade all four of

Updating the recursor is sufficient if you can secure the last mile.
And who wants to use a compromised Internet connection, anyway?

For many sites, upgrading the resolver cannot be avoided because you
typically need NSEC3 support which has become available from vendors
only relatively recently (in addition to basic DNSSECbis support).
Given that the DNSSEC protocol does not actually prevent cache
poisoning, you really, really want to install a superset of your
customers' trust anchors (even if that set is not empty) because
someone might find a bypass for source port randomization which allows
to trivially poison a cache which isn't married to a validator.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Aug 2010 07:13:55 -0700

OOPS, stupid me, this actually WOULD help prevent downgrades.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Aug 2010 07:41:49 -0700

> And who wants to use a compromised Internet connection, anyway?

Dear god no!

Validating on the recursive resolver ranges between useless and dangerous.

If the recursive resolver just simply reports the validation, its useless:  

Our experience with Netalyzr has shown that the recursive resolver can't be trusted, and is in fact the adversary. 

We've seen multiple DNS manipulations, ranging from "benign" policy to a huge amount of NXDOMAIN wildcarding to ISPs which use DNS to man-in-the-middle user's search requests (yes, MITM of google, yahoo, and bing, by multiple ISPs, using DNS!) to malcode-set recursive resolvers that return umm, interesting results for ad.doubleclick.net.

I'd rather trust Bernie Madoff to balance his own books than the recursive resolver to validate DNSSEC.

If the recursive resolver acts on the validation, its dangerous:  99.999% of the DNSSEC failures (if not 100%) will be benign, not malicious (assuming, of course, that the resolver is properly resistant to out-of-path adversaries.). 

Thus any decision to return a SERVFAIL in response to a failure to validate represents a denial-of-service attack, not a security feature.

And the last mile is exactly the MOST insecure part of the network.  It is the last mile (on either end) that you have low volume.  That you have wireless networks.  That you have unauthenticated broadcast domains (ethernet, wireless) where hostile machines are present.  In path adversaries, OTHER than nation-state adversaries or rogue ISPs advertising bad routes, operate almost exclusively in that last mile on one side or the other.  

So its not like you can trust the results returned by the recursive resolver aren't manipulated during that last hop.

Rather, validation must be the exclusive domain of the stub resolver, libaries, and application if you want DNSSEC to have any meaning at all beyond an Internet-scale denial of service attack and full employment act for consultants.  

If the application is "DNSSEC unaware" (using current APIs), it is only the stub resolver that needs to do anything: on any failure of DNSSEC (no trust anchor, bad signature, no DNSSEC information at all), the stub should conduct its own independent request, bypassing the recursive resolver, and ACCEPT THE RESULTS of this independent request, regardless.  (This can be optimized by trusting everything from the recursive resolver that DOES validate, so a cached path, except for the failure and beyond, could be fetched from the recursive resolver).

Now all DNSSEC "failures" become a performance degrader and a load on the failing authorities, not a DOS.  (And this is safe to do!)

If the application is "DNSSEC aware" (using APIs which convey DNSSEC results), then the stub just reports the results of the validation and leaves it to the application to figure out what to do.

> to trivially poison a cache which isn't married to a validator.

As an out of path adversary, you can't "bypass" randomization: with sufficient entropy, it is the same type of protection you get from cryptography: mathematical bounds and calculateable amounts of work.  If you are not comfortable with 2^32-2^40th level work for the attacker (port randomization, randomization + 0x20), the group should adopt Barwood's EDNS0 ping, which converts it to 2^128th level work.  

Between good randomization and good glue policy (eliminate all race-until-win attacks), out of path adversaries are a non-issue for a well constructed resolver.

As an in-path adversary, yes, you can trivially pillage DNS because the randomization becomes meaningless.  But this only matters if the in-path adversary is NOT on the packet-path for the final traffic, because applications are either

a)  Trivially pillaged by the same in-path adversary
or
b)  Not actually trusting DNS, because a DNS manipulation is just another in-path adversary.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Aug 2010 16:07:22 +0100

> recursive resolver to validate DNSSEC.

+1. This is like hanging your door keys on your gate post.

> Rather, validation must be the exclusive domain of the stub resolver,
> libaries, [and] application if you want DNSSEC to have any meaning at all
> beyond an Internet-scale denial of service attack and full employment act
> for consultants.

I think the 'and' I put in []s can be "and/or".

> If the application is "DNSSEC unaware" (using current APIs), it is only
> the stub resolver that needs to do anything: [*] on any failure of DNSSEC 
(no
> trust anchor, bad signature, no DNSSEC information at all), the stub
> should conduct its own independent request, bypassing the recursive
> resolver, and ACCEPT THE RESULTS of this independent request, regardless.
> (This can be optimized by trusting everything from the recursive resolver
> that DOES validate, so a cached path, except for the failure and beyond,
> could be fetched from the recursive resolver).

The stub resolver needs to do something else different before
you get to [*], which is issue queries with DO set in response to
"DNSSEC unaware" calls (gethostbyname etc.). Inspection suggests
this does not happen.

-- 
Alex Bligh

---

From: [email-masked]
Date: Wed, 4 Aug 2010 16:56:55 +0000

> b)  Not actually trusting DNS, because a DNS manipulation is just another in-path adversary.

	tell us how you really feel about intermediate validation :)

	there are some cases where I can see that there is not enough resource in the
	node to run its own validation, but there is enough to run a stub resolver...
	but those are not the norm.

--bill

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Aug 2010 12:05:24 -0700

> I'd rather trust Bernie Madoff to balance his own books than the recursive resolver to validate DNSSEC.

(I suspect Bernie Madoff balanced his own books quite well.  It was the books he showed to others that were the problem.)

I have a pretty high level of trust in the validating resolver I have on my laptop.  It also gives me the side benefit that I can look at the logs when I get a SERVFAIL.  It would be a SMOP to hack the resolver (or watch the logs) to signal a validation failure to a process that pops up a dialog box (or does other actions) to deal with why the validator puked.

> Thus any decision to return a SERVFAIL in response to a failure to validate represents a denial-of-service attack, not a security feature.

A rational policy decsion: "fail close" instead of "fail open".

> So its not like you can trust the results returned by the recursive resolver aren't manipulated during that last hop.

It depends on your trust boundary.  In many enterprises, the folks who run the resovlers are trusted and that's why we have TSIG and/or SIG(0).  Of course, in such environments, you lose the ability of end users to determine why a validation failed, but you gain site wide caching.  In other environments, e.g., residential ISP services, the trust boundary currently incorporates demonstrably untrustworthy parties, so running a validating resolver locally is warranted if you want to trust DNS responses. 

> Rather, validation must be the exclusive domain of the stub resolver, libaries, and application if you want DNSSEC to have any meaning at all beyond an Internet-scale denial of service attack and f…

Doesn't scale.  You're proposing multiplying the load on the DNS infrastructure by the number of applications executing on every machine on the Internet and essentially defeating any real level of caching. 

Running the resolver on the local host at least "only" increases load to the number of machines on the Internet.  Caching at the host level is a bit better than caching at the application level.

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2010 15:31:56 -0400

> Running the resolver on the local host at least "only" increases load to the number of machines on the Internet.  Caching at the host level is a bit better than caching at the application level.

There's no reason not to continue to use your ISP's DNS cache, as long as you validate the answers it gives you, and have a heuristic for learning if it lies, and bypass it if you detect that it does.   The only additional load a validating resolver in the application should create is its own CPU load doing the validations.   A local validating cache would certainly help with that.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 05 Aug 2010 15:04:17 +0200

On 31.7.2010 02:54, Andrew Sullivan wrote:
> how applications get to DNS results,&c, are our problem.  Indeed,

I second that.  dnsext is no place to solve this and it also doesn't 
have the full expertise for that.

> should use the one he is setting up.)

I have already asked for mailing list for Public Keys in DNS (or how we 
are going to call it).

I'll let you know when it's created and we could move this discussion there.

O.
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Aug 2010 18:36:05 +0100

On Wed, 4 Aug 2010, Nicholas Weaver wrote:
>
> Dear god no! Validating on the recursive resolver ranges between useless
> and dangerous.

Not if the resolver runs on the endpoint.

> libaries, and application if you want DNSSEC to have any meaning at all
> beyond an Internet-scale denial of service attack and full employment
> act for consultants.

Stub resolvers (at least in the unix style) don't retain enough state to
perform well, so you need at least some kind of separate caceh on the
endpoint. Something like the bind-9 lwresd seems sensible to me, though it
needs a lot of adaptation to re-focus it on application dnssec support.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH FITZROY SOLE LUNDY FASTNET IRISH SEA: SOUTHWESTERLY OR WESTERLY, VEERING
NORTHWESTERLY 5 OR 6, DECREASING 4 OR 5. MODERATE OR ROUGH. OCCASIONAL RAIN,
THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 6 Aug 2010 10:39:08 -0700

> Not if the resolver runs on the endpoint.

You're right.  When I think of recursive resolver, I think of "separate system"

A better way to have put it is "validating on ANY host other than the endpoint itself ranges between useless and dangerous".

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Aug 2010 17:12:47 -0400

OK, you try validating on my end point.

It has a $1 PIC controller that is not capable of performing RSA or
ECDSA. Looking at having about a thousand of them in the system.

It makes no sense to validate at any point you do not have a trusted channel to.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Aug 2010 22:31:54 +0100

> It makes no sense to validate at any point you do not have a trusted channel to.

The right way of statinthe requirementit, of course :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: EASTERLY 3 OR 4, OCCASIONALLY 5 LATER. MODERATE. RAIN OR
SHOWERS, FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 6 Aug 2010 22:18:02 -0700

> It makes no sense to validate at any point you do not have a trusted channel to.

THen such a PIC is going to get royally fucked by a MitM:

In such a case, DNSSEC only protects such applications when the MitM is only on DNS and not on the final protocol.

And THAT MitM is called the not-on-the-endpoint "recursive resolver".

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Aug 2010 09:31:36 +0000

> Validating on the recursive resolver ranges between useless and

How do you prevent cache poisoning without adding a validator to the
cache?

Keep in mind that a validator behind a non-validating cache has no way
to recover from bad data which has entered the cache.  If you think
that DNS cache poisoning attacks are likely (and why else would you
deploy DNSSEC?), this should be a concern to you.  It might only be a
denial of service, but that could still be quite annoying and cause
significant call center costs.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Aug 2010 08:15:11 -0700

> How do you prevent cache poisoning without adding a validator to the

Out of path attacker cache poisoning is eliminated by a combination of query entropy (if 40b is not sufficient from a combination of port randomization and 0x20, adopt EDNS0 ping) and glue policy (eliminates race-until-win attacks and all attacks using ancillatory data).

Unbound has successfully implemented such policies since shortly after details of the Kaminski attack went public.  

See http://tools.ietf.org/html/draft-weaver-dnsext-fr-comprehensive-00#section-10 for a detailed discussion of such glue policies and the rather negligible performance impact they have (almost no increase in response latency, a ~20% or so increase in query traffic).

That Bind has not implemented these policies I find well, evidence of tragic neglect at best.  There are less charitable explanations.

In-path attacker cache poisoning (where the attacker can see the actual packets) generally does not matter, because such attackers are ONLY relevant in the very rare case where the DNS traffic is NOT on the same path as the final application traffic. [1]

This is why I say that validating on the independent recursive resolver is, at best, useless.

And I lied slightly: there is one attacker who's in path on DNS but not in path on the final traffic: the independent recursive resolver itself, which we have seen in practice is malicious [2].

This is why I say that I'd rather trust Bernie Madoff to audit his books than the independent recursive resolver to validate DNSSEC.

> significant call center costs.

Actually, a validator behind a non-validating cache has a great way to recover from bad data: just do an iterative query and bypass the non-validating cache!  

In fact, I argue strongly that a validator behind a cache should react to ALL DNSSEC failure or even lack of DNSSEC altogether by performing such a fetch, accepting the resulting data regardless of DNSSEC validation, and just using its own (small) cache for efficiency.   Thats hardly hard code to write, and far easier than validating DNSSEC signatures.  [3]

And if you want to talk Denial of Service, that IS validating on the not-end-host cache: 99% of the DNSSEC failures at least (quite possibly 99.9 to 100%) will be misconfigurations etc.  Thus taking any action that results in the name not resolving is NOT improving security, but rather a DOS on DNS.

This is why I say that validating on the independent recursive resolver is most likely dangerous unless the results of validation are always ignored (in which case, why validate?).

[1] Remember, an application using a A/AAAA record from DNS falls into one of two categories: trivially pillaged by the same MitM who could have pillaged the DNS request, OR not trusting DNS because a bad A record is just another MitM. 

[2] Such malice, which we have directly observed with Netalyzr, ranges from the relatively benign (NXDOMAIN wildcarding, site-local blocking policy) to moderately damaging (SERFAIL wildcarding) to the outright malicious (ISPs that MitM search (www.google.com, search.yahoo.com, www.bing.com) using DNS, malicious DNS resolvers that cause ad.doubleclick.net to serve up 'male enhancement' ads).

[3] Yes, this will hammer the authorities for domains that don't do DNSSEC or which have a DNSSEC problem.  You want to have authorities have a reason to deploy DNSSEC, no?  

Because unless you are storing key material or the like in DNS, OR you have some mandate-from-on-high to add useless "security" to say you are secure, deploying DNSSEC on your domain is a Bad Thing (tm): reduces reliability, adds tons of hastle, but doesn't do jack for actual security.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Aug 2010 15:49:20 +0000

* Nicholas Weaver:

> Out of path attacker cache poisoning is eliminated by a combination
> of query entropy (if 40b is not sufficient from a combination of
> port randomization and 0x20, adopt EDNS0 ping) and glue policy
> (eliminates race-until-win attacks and all attacks using ancillatory
> data).

My belief is that this is too tricky to get right.  Until someone
comes up with a formal model for DNS data correctness (that is, a
formal model based on which it is possible to tell whether a resolver
answer is consistent with data it has received from upstream servers)
and at least semi-formally validates an implementation against it,
this is not going to change.

In addtion to that, on IPv4, it is also impossible to move beyond
20-something bits due to network layer characteristics (even EDNS0
does not help there), and you have to rely mostly on the TTL.

> Unbound has successfully implemented such policies since shortly
> after details of the Kaminski attack went public.

> See
> http://tools.ietf.org/html/draft-weaver-dnsext-fr-comprehensive-00#section-10
> for a detailed discussion of such glue policies and the rather
> negligible performance impact they have (almost no increase in
> response latency, a ~20% or so increase in query traffic).

At least some of the advice in that section is incorrect.  For
instance, it is unsafe to return a CNAME even if it is the direct
answer to a query because Kaminsky-style attacks are still possible if
you do that.  In order to plug this hole, you need to check if the
CNAME you've received conflicts with an existing cache entry and
return SERVFAIL if it does.  This has the potential of breaking name
resolution, unfortunately.

I also wonder how your resolution algorithm learns that a new
delegation exists, while still avoiding to cache an incorrect
delegation at an empty non-terminal.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Aug 2010 09:32:25 -0700

> this is not going to change.

What do you find missing in the notion of scoping and validation?

Its actually far simpler and clearer than bailywick checking as its currently done in Bind.

> does not help there), and you have to rely mostly on the TTL.

Uh, actually, this is false:

16B for transaction ID
12B for port #
8+B for 0x20 [1]

EDNS0 ping can add an arbitrary amount of additional entropy if adopted.

That Bind does not even do 0x20! I find remarkable in its absence.

[1] If you eliminate all ancillatory data attacks, the 1.123.com kaminski variant doesn't matter, so it becomes the 0x20 entropy for the actual name targeted, which makes it 8+B in real word practice.

> resolution, unfortunately.

no, because if you have an existing cache entry you don't do a query at all.

This is safe:

If X is not in the cache, query for X from the authority returns

X CNAME Y
Y A Z

There are two options, BOTH of which are safe from a kaminski variant.

A:  Collapse the CNAME (Ota's suggestion from a long time ago) to be X A Z and return it.

B:  Cache X CNAME Y, do a new fetch for Y if Y is not already cached.

In both cases, an attacker can't trigger a race-until-win with an out of path injected reply.  Because Y A Z is not introduced into the cache in either case without a separate fetch, so an attacker who wants to inject Y A Z into the cache by querying for a series of X's, if the resolver implements case A the attacker can't do anything for Y with this, and if the resolver implements case B, a successful race only triggers another race (to poison Y A Z)

There are resolvers that don't blindly accept CNAME chains, instead doing B.  (We test for this in Netalyzr, see cname.n1.netalyzr.icsi.berkeley.edu ).  It doesn't break things to do so.

> delegation at an empty non-terminal.

This is the observation that the other use of ancillatory data is voiding data.  Doing a new independent fetch triggered on such conflicting ancillatory is safe, because that requires a double-race-until-win, which is exponentially harder for an attacker.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Aug 2010 12:52:37 -0400

Dear colleagues,

> Its actually far simpler and clearer than bailywick checking as its currently done in Bind.

[&c.]  I can find nothing in this message about using DNSSEC in
applications nor about the DNSEXT charter.

Moreover, Olafur and I have already made it clear that DNSSEC in
applications, apart from any new RRTYPE, is just not going to be
on-charter for this WG.  To begin with, it needs to attract attention
of applications types, and we have a recent example of the apparent
indifference of applications area participants to what goes on in
DNSEXT.

So, if one wants to continue exploring this part of the maze, I urge
you at least to change the subject line.

Thanks,

A (as moderator)

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Aug 2010 16:59:49 +0000

> Uh, actually, this is false:

There is a hidden assumption there concerning atomic message delivery,
which is just not provided by the network layer (at least for IPv4,
IPv6 is much closer).

> no, because if you have an existing cache entry you don't do a query

What you do if you've got an A RR in cache, and receive a QTYPE=AAAA
query?  You send out a new upstream transaction, and you might receive
a CNAME for that.  What do you do with it?

Problems like this are the reason why we need a formal model.
Otherwise, we can't be sure that we've covered all corner cases.

> This is the observation that the other use of ancillatory data is
> voiding data.  Doing a new independent fetch triggered on such
> conflicting ancillatory is safe, because that requires a
> double-race-until-win, which is exponentially harder for an
> attacker.

So you propose to query the parent again at the newly found delegation
point?  Wouldn't that double the query load on delegation-centric
zones?

At that cost, it's better to get rid of the amplification effect of
caches altogether and cache responses for delivery to clients only
after they have stabilized.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Aug 2010 14:20:37 -0300

On Mon, Aug 9, 2010 at 12:15 PM, Nicholas Weaver
<[email-masked]>wrote:

> [snip]

>
> And I lied slightly: there is one attacker who's in path on DNS but not in
> path on the final traffic: the independent recursive resolver itself, which
> we have seen in practice is malicious [2].
>

s/is/can be/ - there are plenty of non-malicious third-party resolvers
(where "plenty" needs only be "at least one").

> Actually, a validator behind a non-validating cache has a great way to
> recover from bad data: just do an iterative query and bypass the
> non-validating cache!
>
> In fact, I argue strongly that a validator behind a cache should react to
> ALL DNSSEC failure or even lack of DNSSEC altogether by performing such a
> fetch, accepting the resulting data regardless of DNSSEC validation, and
> just using its own (small) cache for efficiency.   Thats hardly hard code to
> write, and far easier than validating DNSSEC signatures.  [3]
>
>
I expect that those end-user (hosts) who want validation, who don't have a
resolver that validates, at this stage, to be sufficiently knowledgeable
and/or resourceful enough, to install personal validating recursive
resolvers, thus avoiding your suggested "clever" idea.

I see no reason to suspect the possibility that non-validating caches are
likely to remain a long-term issue - or even a short-term issue.

> [3] Yes, this will hammer the authorities for domains that don't do DNSSEC
> or which have a DNSSEC problem.  You want to have authorities have a reason
> to deploy DNSSEC, no?
>
> Because unless you are storing key material or the like in DNS, OR you have
> some mandate-from-on-high to add useless "security" to say you are secure,
> deploying DNSSEC on your domain is a Bad Thing (tm): reduces reliability,
> adds tons of hastle, but doesn't do jack for actual security.
>
>
Sorry, going to have to call BS on this one. (But Sir!)

The Kaminsky style attack is only possible because the resolver _is_ a
resolver, and scales well for the attacker because the multiplier effect
(resolver -> stubs) yields significant numbers of victims. The quantity of
victims is only relevant if the domain "target" can be spoofed/poisoned, and
has intrinsic value (e.g. somewhere users would expect to enter sensitive
information, like a bank or on-line purchase site.)

Even if the stub resolvers do not validate, having recursive resolvers that
validate and authority servers that serve DNSSEC answers, removes the
Kaminsky vector entirely -- for _those_ domains and _those_ resolvers'
clients.

The effort/return on trying to attack individual users' stub connections to
resolvers is several orders of magnitude harder than attacking recursive
resolvers. There is no mechanism to trigger the client to make queries to
domains of the attackers choosing. There is no way for the attacker to know
apriori what the recursive resolver being used is, on a specific IP address
basis. And the benefits of attacking a single user are extremely minor,
relatively speaking.

This means that there is intrinsically competitive pressure amongst
content-side folks (like banks or online retailers) to implement DNSSEC, and
competitive pressure among third-party resolver operators to deploy
validation. Enterprise resolvers have intrinsic regulatory pressure and/or
owner/shareholder pressure to deploy validation.

Once those pressures are visible in the marketplace, the pattern of adoption
rates will resemble those of an epidemic - slow start ramping up, starting
exponentially and eventually tailing off after the 50% mark. There will
always be tail-enders.

Note that the benefits are seen even without end-node (stub resolver)
implementation. Further benefits are seen once stubs implement too.

And competitive pressure helps adoption of DNSSEC, rather than your theory
of being an impediment.

Brian

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Aug 2010 14:14:23 +0100

> resolvers, thus avoiding your suggested "clever" idea.

You can implement something like this idea by configuring BIND to use a
forwarder with the "forward first" option. (It probably doesn't have quite
the right fail-over logic, though.)

The main problem is likely to be with end hosts behind a firewall that
blocks DNS queries which do not go via the network's recursor.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHWEST, VEERING NORTHWEST, 5 OR 6. SLIGHT OR MODERATE. SHOWERS,
THUNDERY AT FIRST. MODERATE OR GOOD.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 14 Aug 2010 22:20:42 -0400

On 8/9/2010 11:15 AM, Nicholas Weaver wrote:
> of
query entropy (if 40b is not sufficient from a combination of port
randomization and 0x20, adopt EDNS0 ping) and glue policy (eliminates
race-until-win attacks and all attacks using ancillatory data).

It seems to me that you can almost totally eliminate race-until-win by
looking to see if a second packet arrives on the same interface/port
claiming to answer the same query. Since you have no way of knowing
whether the good or bad packet arrived first you drop both of them. It
is better to try again with a different DNS server for the required
data. There is no need for special signaling like EDNS0 ping or 0x20,
just look for unexpected second packets.

Danny