Subject: Re: [ietf] DNS spoofing at captive portals

From: Alfred Hönes <[email-masked]>
Date: Fri, 24 Sep 2010 14:38:51 +0200 (MESZ)

At Fri, 24 Sep 2010 07:21:21 -0400,  Michael Richardson wrote:

> Has the IETF (or rather then IAB) written any simple documents that
> explain to less informed (i.e. marketing/product) managers why it
> is a bad thing for a captive portal to spoof DNS replies?
> (not just in regard to DNSSEC, but also in regards to just caching)

a) Most of the arguments explained in the 2003 IAB Commentary:
   "Architectural Concerns on the use of DNS Wildcards",
   <http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html>,
   apply in a similar fashion, but it indeed would be a good idea
   to produce such document.  I think much text from 2003 could
   be leveraged.

b) It should be clearly spelled out that this practice falls among the
   category of actions commonly known as man-in-the-middle attacks.

c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
   descibe these "services" in a much too friendly tone;
   terms like "service" and "benefits for users" are clearly
   abuse of language -- the above IAB statement already indicates
   that similar interference with the DNS causes severe damage
   to user perception and performance.
   These drafts should clearly spell out the downside of these
   methods and their fundamental nature, being MitM attacks.

d) In my personal opinion, the original idea of having recursive
   DNS resolvers located "close to the hosts" should be given more
   traction again in the future.  All kinds of SOHO access gateways
   or home gateways should preferably offer (locally) full recursive
   and validating DNS resolution service.  The ISP-based DNS recursor
   was (and perhaps still is) a good idea in low-bandwidth (dial-in)
   access networks, where the (bandwidth and monetary) costs of full
   DNS service actually matter and are detrimental for the users, but
   it does not make sense any more for broadband access networks with
   (almost) bandwidth-usage independent billing models (flat rates).

   Thus the dependency on (both technically and policy-wise!) powerful
   "central" caching resolvers could be reduced dramatically.
   DNSSEC validation makes most sense for applications when performed
   as close as possible to the stub resolver, if the latter cannot
   perform this function itself; this way, the unprotected path
   at least is constrained to within the users' sites and hence their
   own "administrative domain".
   Experience has shown that huge central resolver systems are very
   attractive targets for external attacks as well as for insider
   attacks (like ${subject}).

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

-

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 12:00:49 -0400

This document is probably relevant, although it goes the route of  
"providing guidelines for minimum breakage" rather than forbidding.
<http://tools.ietf.org/html/draft-livingood-dns-redirect-02>

On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote:

>  Alfred HÎnes.
> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+
>
> -
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 24 Sep 2010 18:18:16 +0000

>> c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect

draft-livingood-dns-malwareprotect concerns what is primarily an opt-in
service to block known malware sites for end users.  Hopefully that is
less controversial than the redirect one, but who knows.

draft-livingood-dns-redirect was written to do two things.  First was to
document a relatively long-standing process in a reference-able IETF
document where no documentation previously existed.  Second was to
document the best or least worst way to approach it, if a party was
planning to do so.  Since that time, I've added a bunch of stuff related
to DNSSEC to make clear an incompatibility there.  I'm a bit conflicted
though about whether to keep it as informational or consider historic.

In any case, as noted below, I'm more than happy to consider any text that
might improve these document by providing more information on opposing
viewpoints, etc.

>>   abuse of language -- the above IAB statement already indicates

Sorry you feel that way.  Operators view these as services and describe
them as such, so I am simply using that language.  As I do my next pass
through the documents I will review it for any non-neutral descriptors. Of
course, also feel free to email me a list of the ones you think I should
consider revising in some manner.

>>   to user perception and performance.

The 2nd draft concerns protection from malware, which is generally assumed
to be a service that users opt-into (a la OpenDNS, etc.).  Those users who
have decided to use such services very likely are much more concerned with
malware than the fact that FQDNs associated with malware would be blocked.
 Again, I'm quite willing to include text you wish to propose to capture
alternative viewpoints and criticisms, as that's an important part of such
a document IMHO.

>>   methods and their fundamental nature, being MitM attacks.

I'm happy to consider any text you would like to propose, and am quite
willing to include specific notes that some in the community consider the
techniques MitM attacks, in order to try to capture all viewpoints on the
subject.  Feel free to send any proposed text to me via email.

Regards,
Jason

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Sep 2010 12:00:32 -0700

At 6:18 PM +0000 9/24/10, Livingood, Jason wrote:
>I'm a bit conflicted

If it describes something that you believe is currently deployed, even if you think that deployment is non-optimal, it should be marked as Informational.

--Paul Hoffman, Director
--VPN Consortium

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Sep 2010 15:46:05 -0400

>   to produce such document.  I think much text from 2003 could

One important thing to realize is that this kind of "service" isn't always implemented using wildcards.  Sometimes the "service" is implemented using interception proxies.

>   category of actions commonly known as man-in-the-middle attacks.

Agreed.  Actually, when a server or interception proxy deliberately misrepresents the contents of others' DNS zones, the appropriate term (IMO) is "fraud".   

IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected.

>   descibe these "services" in a much too friendly tone;

Strongly agree, at least for the -redirect draft.  At the very least, a distinction needs to be made between services which the individual user deliberately chooses, and services which are imposed without the users' knowledge or consent.  The draft also glosses over the problems created by this practice for all applications other than web browsing by human beings.   Not only does this provide misleading error indications for all other applications, it even breaks applications that are layered on top of HTTP.

>   and validating DNS resolution service.

Agree with this also.  In many cases the ideal model seems to be one in which the host serves as its own primary DNS server, or at least as the master DNS zone. 

Keith

---

From: John Levine <[email-masked]>
Date: 24 Sep 2010 21:17:19 -0000

>IANAL but would think that such practice should expose the operator
>of the server or proxy to civil and/or criminal action, both from the
>operators of the zones whose RRs are being misrepresented, and from
>the users' whose applications are affected.

I'm not a lawyer either, but I at least know that fraud requires
intent.

If a naive user clicks on a link in spam, and the DNS cache intercepts
the request and returns a pointer to a warning page rather than a
Ukranian malware site, that's not fraud, that's a service.  If you
claim otherwise, people will look at you quizzically, like you're
spouting nonsense, which under the circumstances would be
understandable.  It also reinforces the perception that the IETF is
out of touch and hasn't noticed that it's no longer 1990.

Any analysis of DNS spoofing needs to take into account intentions and
tradeoffs.  On networks of consumer PCs, intercepting requests for
malware sites is a 100% win.  I'm not thrilled about the practice of
replacing NXDOMAIN with the A record of a page of links to lexically
similar web sites, but the actual harm of doing that on consumer
networks (not networks with servers) is pretty hard to show.
Replacing a valid record that isn't a pointer to malware with another
is indeed bad, but I don't know anyone who does that.

R's,
John

---

From: Steven Bellovin <[email-masked]>
Date: Fri, 24 Sep 2010 17:45:06 -0400

> is indeed bad, but I don't know anyone who does that.

It will be interesting to see what will happen to these "services" when DNSSEC is used more widely.

Me -- VPNs are your friend; I use them to deflect all sorts of damage.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "John R. Levine" <[email-masked]>
Date: 24 Sep 2010 18:34:53 -0400

> It will be interesting to see what will happen to these "services" when DNSSEC is used more widely.

Plan A: few consumers will use DNSSEC between their PCs and the ISP's 
resolver, so they won't notice.

Plan B: consumers will observe that malicious impersonation of far away 
DNS servers is rare and exotic, but malware spam arrives hourly, so they 
will make a rational tradeoff, take their ISP's advice, and turn off 
DNSSEC.

Malware that infects browsers and rewrites bank transactions on the fly is 
a huge problem, particularly in Europe, and requires no DNS funny business 
at all.  We can certainly imagine attacks that depend on DNS poisoning, 
but any tradeoff that makes it easier to get infected by malware is, for 
typical PC users, a foolish one.

Be careful what you ask for, and all that.

R's,
John

---

From: John Levine <[email-masked]>
Date: 25 Sep 2010 00:16:22 -0000

>will make a rational tradeoff, take their ISP's advice, and turn off 

Something else occurs to me:

Plan C: Sophisticated ISPs might configure their own DNSSEC key into
customer resolvers, and sign replacement records with that.

The threat model for DNSSEC has always been, approximately, that the
authoritative server at the far end is friendly, and the middleboxes
are hostile.  But we have real situtations where the opposite is true,
quite possibly more often than the other way around.

If we want people deploying DNSSEC widely, we need to make sure it
handles the actual threats they face.

R's,
John

PS: If I plug my random Windows PC or Mac into a cable modem, and I tell
it to use DNSSEC, where does it get the top level validation keys?

---

From: bill manning <[email-masked]>
Date: Fri, 24 Sep 2010 18:10:50 -0700

> quite possibly more often than the other way around.

presuming your statement about an inversion of the stated trust model is correct,
can we dereference "friendly" and "hostile" to whom?  Who makes that assessment
and who/what defines the tools to implement a trust policy?

--bill

---

From: "John R. Levine" <[email-masked]>
Date: 24 Sep 2010 21:31:09 -0400

> presuming your statement about an inversion of the stated trust model is 
> correct, can we dereference "friendly" and "hostile" to whom?  Who makes 
> that assessment and who/what defines the tools to implement a trust 
> policy?

Those are all excellent questions, and if I had good answers I would 
answer them.

I suspect that for most consumer ISP users, their least bad choice is to 
get their trust policy from the ISP.  The ISP may well be awful, but for 
nontechnical broadband users, it is less awful than any plausible 
alternative I can think of.  They want to maximize their revenue, but they 
probably don't want to install spambots on your PC and wire the contents 
of your bank account to Belarus.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Sep 2010 16:42:11 -0400

On Sep 24, 2010, at 5:17 PM, John Levine wrote:

> Ukranian malware site, that's not fraud, that's a service.

No, it's still fraud.  You might personally believe that it's okay for an ISP to do harm to a site that it believes is distributing malware, but a court of law might see it differently.  Nobody has given the ISP the authority to misrepresent others' DNS zones.

I want my ISP to deliver packets to their destination addresses, not to try to second-guess which destination addresses I actually want to talk to.  That is completely outside of their area of competence.

Nor is it within the ISP's competence to decide that HTTP needs to work well (according to its definition of "well") at the expense of all other applications.

Now if an ISP allows users to opt-in to such a service, telling its prospective customers what it's going to do to DNS responses and explaining to them all of the various ways that their "service" can harm applications, that's a different matter.  

Keith

---

From: David Conrad <[email-masked]>
Date: Sat, 25 Sep 2010 17:24:50 -0700

[I suspect you may know much of this, but just in case...]

>> resolver, so they won't notice.

In general, consumers won't be using DNSSEC between their PCs and ISPs.  PCs typically use stub resolvers and while there are ways to secure the communication between the stub resolver and the ISP's (perhaps validating) resolver, namely SIG(0) or TSIG, I don't know of any implementations that make this easy enough for your average end user to use and in the case of TSIG, (symmetric) key management will be a bear.

Given existing prevalent technology, you either trust your ISP and the communication path between yourself and that ISP or you run your own validating resolver.  Note that if you take the latter route, you'll often find yourself frustrated when you try to roam on services like T-Mobile Hotspot (you _must_ use their resolver for initial validation).

>> will make a rational tradeoff, take their ISP's advice, and turn off 

Not sure I see the relationship between malware spam and DNSSEC.

Given most validation occurs at the ISP, in the case of an actual DNSSEC-preventable attack the end user will most likely get a friendly message from their web browser saying "can't find the server" or perhaps bounced mail because the destination email address didn't resolve.  The end user will then call the ISP and say "Internet's broke.  Fix it!".  In the cases where an actual cache poisoning attack is taking place (which, I'm told, is actually occurring thanks to scripts that implement the "Kaminsky Method"), the ISP end user support staff can say "Hah! We protected you from Evil!".  In the (likely more frequent) cases where a signature has expired or there is some other misconfiguration, the ISP end user support staff can say "try this IP address". If the domain is popular enough, the ISP could even pre-populate their cache with the correct IP address so they stop getting support calls. However, I suspect if enough of the misconfiguration-variety of validation failures occur, the ISP will get tired of the additional support cost and turn off DNSSEC.

> customer resolvers, and sign replacement records with that.

Given current technology, I suspect this would be rather unlikely since it implies the customer is bright enough to set up their own validating resolver. In such cases, I'd think the customer would question why their ISP is asking them to use an ISP-specific trust anchor.

> are hostile.  

It's more that the authoritative server is ... well, authoritative and that anything in between can't really be trusted. 

> But we have real situtations where the opposite is true,

Hmm.  Are you talking about SiteFinder-like services?

> handles the actual threats they face.

As I mentioned, I have been told by reputable sources that folks are actually experiencing the Kaminsky method cache poisoning attacks, so that threat is real. 

The problem is that some folks have been trumpeting DNSSEC as a solution to many problems when in fact, it solves a relatively rare (albeit real) attack.  All DNSSEC really does is ensure a DNS response hasn't been mucked with in transit from the authoritative server to the validating resolver.  DNSSEC can't help you between the validating resolver and the originating requester if you can't trust that path and it can't help you if you can't trust the authoritative server.

DNSSEC may be used as a trustable infrastructure to allow folks to do other things (see the keyassure proto-wg), but that's in the future...

> it to use DNSSEC, where does it get the top level validation keys?

In order to use DNSSEC (at least today), you have to run a validating resolver on your PC or Mac and you have to specify the trust anchor(s) in the name server configuration file.  The trust anchor you'd most likely want to configure is available from http://data.iana.org/root-anchors/. Presumably, if you're ambitious enough to figure out how to run your own validating resolver, you'll be able to figure out how to add the trust anchor to your config file.  Or at least that's the theory...

Regards,
-drc

---

From: "John R. Levine" <[email-masked]>
Date: 25 Sep 2010 22:34:15 -0400

> Not sure I see the relationship between malware spam and DNSSEC.

See below.

> Hmm.  Are you talking about SiteFinder-like services?

Not really.  There turn out to be a significant number of domains, in the 
hundreds of thousands at least, that are purely evil.  Some host websites 
with drive-by malware installs, with victims pointed there by links in 
spam or various malicious SEO tricks in search engines.  Some are command 
and control (C&C) hosts that existing bots use to update themselves and 
get new instructions.  Last year the Conficker Working Group did a great 
deal of quiet work preemptively registering or reserving the domains that 
the conficker 'bot tried to use to contact C&C.  See this for more info

 	http://www.confickerworkinggroup.org/wiki/pmwiki.php/TLD/TLDOperators

They were reasonably successful until the bad guys switched to ccTLDs that 
were less cooperative about reserving domains.  Unless you are a malware 
researcher, it is overwhelmingly likely that any request for one of those 
domains is from a 'bot, not from you, and if a large ISP like Comcast 
intercepts them, it makes a significant difference to the amount of active 
malware on their networks.  I have even heard of ISPs redirecting C&C 
requests to a local server that sends the bot instructions to turn itself 
off.  (I don't know whether Comcast does that, and I doubt they'd tell me 
if I asked.)

As I said in a previous message, I am not a big fan of rewriting NXDOMAIN, 
and I was on one of ICANN's advisory committees and helped them get rid of 
Sitefinder, but if an ISP does it on consumer networks where there aren't 
supposed to be servers, the damage from doing so is hard to show, so I'm 
not inclined to make a big deal about it.

So anyway, there are some good reasons for ISPs to mess with the DNS 
results their caches provide their users.  If we ask them to use tools 
that will keep them from doing so, it won't happen.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Sun, 26 Sep 2010 17:26:42 +0100

> customer resolvers, and sign replacement records with that.

DNSSEC's validation model makes this basically impossible. The customer resolvers would have to know ahead of time which names will be overridden by their ISP and so may be validated by the extra trust anchor.

Plan D: ISPs that want to block the DNS for evil domains just return a server failure response for the appropriate queries.

See also Paul Vixie's RPZ proposal.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 27 Sep 2010 09:51:34 +0200

Hi John,

On 09/26/2010 04:34 AM, John R. Levine wrote:
> Not really.  There turn out to be a significant number of domains, in
> the hundreds of thousands at least, that are purely evil.  Some host

So, if DNSSEC is enabled with an end-host validator and the ISP cache
returns a different record for such a domain, the DNSSEC validator will
mark it as bogus and the user gets a serverfailure response.  The domain
cannot be accessed.  This is exactly right.

DNSSEC provides integrity checks, it does not synthesize the original
data out of thin air.  Thus, domains can be blocked.

> 
> As I said in a previous message, I am not a big fan of rewriting
> NXDOMAIN, and I was on one of ICANN's advisory committees and helped

Showing an advert then, does not work.  Of course, showing an advert on
someone elses domain name is not particularly nice.

So, an ISP can provide a DNSSEC-enabled cache (that can validate as
well), and can block malware, and end-users can use that cache, and run
their own validator to secure the path to the ISP cache.  So, an
end-user can run a validator that is still a 'stub' that connects to the
ISP cache.  This is much more efficient too as the ISP cache has all the
data (and DNSSEC signatures) in its cache.

A remaining stumbling block (well, once the ISP runs a DNSSEC cache), is
the cablemodem-thingy, but it turns out these can (very often) be
circumvented by providing the validating-stub on the end-users machine
with the direct IP-address(es) of the ISP cache.

Best regards,
   Wouter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Sep 2010 22:11:49 -0400

The point raised by John Levine is amongst my concerns.

And one of the reasons that I have been looking at a different approach to
the use of DNSSEC information that does not change the DNS model as
radically as the end to end DNSSEC model.

The idea of using DNS resolver as a proxy is a good one in my view. The
problem with that model comes from the broken idea that a mobile host should
accept any DNS service offered via DHCP.

A DNS resolver is a trusted service, a host should not take just any DNS
resolver, it should choose a resolver and establish a secure connection to
it that at a minimum provides authentication but should ideally provide
confidentiality as well.

This is the case irregardless of whether DNSSEC is deployed or not. A DNS
resolver is a trusted intermediary even in the case that DNSSEC deployment
at servers is ubiquitous and clients are capable of DNSSEC end-to-end.

Once we have a model in which the DNS resolver relationship is trusted and
the communication to that resolver is secured, it is possible to use the DNS
resolver in much more interesting ways.

An end host can no more make sense of DNSSEC information on its own than a
single mail server can deal with spam effectively. A DNS resolver with
substantial throughput can collect the state data necessary to apply DNS
information intelligently.

DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.

I do not want to connect my machines to every domain in the ICANN DNS
repository. And I certainly don't want ICANN to start restricting issue of
domains to people I or anyone else approves.

DNSSEC can tell my resolver what the authoritative DNS registry is. But that
resolver will then edit that registry to remove the domains that do not meet
my security criteria.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Sep 2010 22:16:05 -0400

That is not the right question.

The question should be, who chooses for me?

My answer to the question does not have to be the same as other people's.
Some people will want the full ICANN registry with every scammy malware site
and every DNS name registered five minutes ago. Others will prefer to have
only the ones proven safe.

If I was running a power station in the US, I would probably be quite happy
with a very short list indeed.

Gen Alexander is proposing a separate network for critical infrastructure. I
think that an edited DNS could play a very important role.

On Fri, Sep 24, 2010 at 9:10 PM, bill manning <[email-masked]> wrote:

> correct,

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

---

From: [email-masked]
Date: Sat, 25 Sep 2010 03:34:54 +0000

actually, it was the right questions... and the answers all distill 
down to your reply.  "security" and trust are in the eyes/validator
of the beholder.  Sam Weiler borrowed the term "local policy" - which
trumps any middleman.  Steve B. suggests VPNs (or their functioal 
eqivalant) between the authoritative or trusted source and the end-system
validator - where in this context, the validator/resolver is w/in a couple
usec of the application; e.g. in the same box.  

you can do it yourself or you can outsource it to someone else.  end of the
day, its the end-system operators choice. the tools for crisply defining 
the constrainsts of local policy are still very crude/fuzzy/undefined.

--bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Sep 2010 17:52:55 -0400

I don't see why DNSSEC makes dropping out zones impossible.

All DNSSEC does is to enable the end point to know that there is data
missing. It does not provide the end zone with any way to find the missing
data, nor is there any user interaction that makes any real sense in that
situation.

But the real answer to the problem is that the root zone signature is not
the root of trust for my DNS, it is the root of trust for the ICANN DNS.

myDNS = icannDNS - maliciousDNS

I plan to publish my root cert for my zone at the apex of my DNS zone and
establish that out-of-band as the trust anchor for every device and
application in my network.

Hosts in my network will determine that a secure DNS resolver is available
for the zone via the ESRV mechanism I recently proposed and establish a
secure tunnel with my DNS resolver via a protocol TBS, but probably based on
either the TLS handshake to establish a ticket containing all necessary
server-side state or the existing (but rather old and needing much revision)
TKEY mechanism and either TSIG or a cryptographic packaging mechanism TBS.

It would also be possible to adapt either DTLS or IPSEC. But neither of
those is well suited to use as a security wrapper for DNS for reasons I
won't go into here.

On Sun, Sep 26, 2010 at 12:26 PM, Tony Finch <[email-masked]> wrote:

> On 25 Sep 2010, at 01:16, John Levine <[email-masked]> wrote
> >
> DNSSEC's validation model makes this basically impossible. The customer
> resolvers would have to know ahead of time which names will be overridden by
> their ISP and so may be validated by the extra trust anchor.
>
> Plan D: ISPs that want to block the DNS for evil domains just return a
> server failure response for the appropriate queries.
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 27 Sep 2010 15:48:14 +0100

> appropriate technology for intra-domain trust.

Why not?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: bill manning <[email-masked]>
Date: Mon, 27 Sep 2010 09:31:34 -0700

>> appropriate technology for intra-domain trust.

	Because the "atomic" unit of DNSSEC is a domain/zone/delegation, not a specific RRset.
	Everything in a domain has the exact same threat model.

--bill

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Sep 2010 09:23:00 +0100

On 28 Sep 2010, at 02:20, Phillip Hallam-Baker <[email-masked]> wrote:
> On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch <[email-masked]> wrote:
> Because the root of trust for any enterprise is the enterprise itself. Not ICANN.

DNSSEC does not require you to use only ICANN's trust anchor. You can also use your enterprise trust anchor, so you can validate your enterprise DNS independently of any third party.

(The keyassure work might make this approach to key distribution easier than running an enterprise X.509 CA. DNSSEC also has the advantage of a defined trust anchor rollover protocol.)

You can also use third party trust anchors such as the ISC's DLV.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Sep 2010 21:20:08 -0400

Because the root of trust for any enterprise is the enterprise itself.

Not ICANN.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 11:03:00 -0400

The most frustrating part about DNSSEC is that trying to pin down what it is
and what it is not, what it is trying to do and what it is not is like
trying to nail jello to a wall.

Whenever an issue is raised with the DNSSEC protocol, someone immediately
shoots back the reply 'well we are not trying to solve that problem'. Which
is of course really easy when there is no clear statement of what real world
security issues that DNSSEC is trying to deal with.

Blocking one attack does not come close to justifying the cost of DNSSEC
deployment.

Is DLV a part of DNSSEC or not? I am not sure.

DLV is presented as being a stopgap, an interim measure to go away with full
DNSSEC deployment.

What I do know is that I want to use secure DNS in devices that are not
capable of performing public key cryptography. And even if every end point
device is capable of performing RSA2048 operations in acceptable time, I do
not want to push my trust management criteria out to my network endpoints.

On Tue, Sep 28, 2010 at 4:23 AM, Tony Finch <[email-masked]> wrote:

> On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch < <[email-masked]>[email-masked]>wrote:
>
> DNSSEC does not require you to use only ICANN's trust anchor. You can also
> use your enterprise trust anchor, so you can validate your enterprise DNS
> independently of any third party.
>
> (The keyassure work might make this approach to key distribution easier
> than running an enterprise X.509 CA. DNSSEC also has the advantage of a
> defined trust anchor rollover protocol.)
>
> f.anthony.n.finch  <[email-masked]>   <http://dotat.at/>http://dotat.at/
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Sep 2010 07:27:26 +1000

In message <[email-masked]>, Phil
> trying to nail jello to a wall.

DNSSEC is a tool.  It can be used in lots of ways.  It can be configured in
lots of ways.
 
> Blocking one attack does not come close to justifying the cost of DNSSEC

It's designed to block a whole series of attacks and to be an enabling
tools to do other things which are not possible with a insecure DNS.
 
> Is DLV a part of DNSSEC or not? I am not sure.
 
DLV fills one of the left to the user how to do this parts of DNSSEC.
How to distribute/configure the trust anchors DNSSEC needs to do
its job.  It uses DNSSEC to secure that distribution and requires
one configured trust anchor to boot strap the process.  This is
conceptually no different to what IANA did with its ITAR.

This is how it was presented to the IESG when the DLV record was being
allocated.

> DLV is presented as being a stopgap, an interim measure to go away with full

Which deals with which trust anchors are added and removed from the
collection and when that is done.

> not want to push my trust management criteria out to my network endpoints.

Which is perfectly possible to do with DNSSEC + TSIG or DNSSEC + SIG(0) or
DNSSEC + GSS-TSIG or DNSSEC + IPSEC or ....

> --001636e0a79c19803a04915324b4
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div>The most frustrating part about DNSSEC is that trying to pin down what=
>  it is and what it is not, what it is trying to do and what it is not is li=
> ke trying to nail jello to a wall.</div><div><br></div><div>Whenever an iss=
> ue is raised with the DNSSEC protocol, someone immediately shoots back the =
> reply &#39;well we are not trying to solve that problem&#39;. Which is of c=
> ourse really easy when there is no clear statement of what real world secur=
> ity issues that DNSSEC is trying to deal with.</div>
> <div><br></div><div>Blocking one attack does not come close to justifying t=
> he cost of DNSSEC deployment.</div><div><br></div><div><br></div><div>Is DL=
> V a part of DNSSEC or not? I am not sure.=A0</div><div><br></div><div>DLV i=
> s presented as being a stopgap, an interim measure to go away with full DNS=
> SEC deployment.=A0</div>
> <div><br></div><div>What I do know is that I want to use secure DNS in devi=
> ces that are not capable of performing public key cryptography. And even if=
>  every end point device is capable of performing RSA2048 operations in acce=
> ptable time, I do not want to push my trust management criteria out to my n=
> etwork endpoints.</div>
> <div><br></div><div><br></div><div><br></div>On Tue, Sep 28, 2010 at 4:23 A=
> M, Tony Finch <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">dot@dot=
> at.at</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
> =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
> ing-left:1ex;">
> <div bgcolor=3D"#FFFFFF"><div class=3D"im"><div><span>On 28 Sep 2010, at 02=
> :20, Phillip Hallam-Baker &lt;<a href=3D"mailto:[email-masked]" target=3D=
> "_blank">[email-masked]</a>&gt; wrote:</span><br></div><blockquote type=
> =3D"cite">
> <div><div><div><div class=3D"gmail_quote">On Mon, Sep 27, 2010 at 10:48 AM,=
>  Tony Finch <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D=
> "_blank"></a><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=
> </a>&gt;</span> wrote:<br>
> 
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><div>On Fri, 24 Sep 2010, Phillip Hallam-Bak=
> er wrote:<br>
> &gt;<br>
> &gt; DNSSEC is a mechanism for establishing inter-domain trust. It is not a=
> n<br>
> &gt; appropriate technology for intra-domain trust.<br>
> <br>
> </div>Why not?</blockquote></div><br></div><div><span>Because the root of t=
> rust for any enterprise is the enterprise itself.<span>=A0</span>Not ICANN.=
> </span></div></div></div></blockquote><br></div><span>DNSSEC does not requi=
> re you to use only ICANN&#39;s trust anchor. You can also use your enterpri=
> se trust anchor, so you can validate your enterprise DNS independently of a=
> ny third party.</span><div>
> <span><br></span></div><div><span>(The keyassure work might make this appro=
> ach to key distribution easier than running an enterprise X.509 CA. DNSSEC =
> also has the advantage of a defined trust anchor rollover protocol.)<br>
> <br></span><div><span>You can also use third party trust anchors such as th=
> e ISC&#39;s DLV.</span></div><div class=3D"im"><div><span><br><div>Tony.</d=
> iv>--<div>f.anthony.n.finch =A0&lt;<a href=3D"mailto:[email-masked]" target=
> =3D"_blank">[email-masked]</a>&gt; =A0<a href=3D"http://dotat.at/" target=3D"=
> _blank"></a><a href=3D"http://dotat.at/" target=3D"_blank">http://dotat.at/=
> </a></div>
> </span></div></div></div></div></blockquote></div><br><br clear=3D"all"><br=
> >-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com=
> /</a><br><br>
> 
> --001636e0a79c19803a04915324b4--
> 
> --===============1131113753==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============1131113753==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 21:01:04 -0400

On Tue, Sep 28, 2010 at 5:27 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <[email-masked]<[email-masked]>>,
> Phil
> lip Hallam-Baker writes:
> >

But which of those ways are people prepared to stand behind and for which
ones am I going to be told 'we aren't trying to solve that problem'.

> DNSSEC + GSS-TSIG or DNSSEC + IPSEC or ....

That is four different possible ways, none of which I would describe as
perfect. In addition there is TKEY + TSIG (RFC2930).

This is a standards organization, there is a difference between four
possibilities based on existing standards and a 'standard' in my view. We
certainly have the basis for developing that type of standard, but to claim
that we have one when there a five options and no understanding of the
tradeoffs is a little previous in my view.

Having looked at deployment of these schemes on a resolver large enough to
have a high probability of DNSSEC cache hits, I cannot see a way to make the
existing schemes work without making the performance issues of DNSSEC worse,
which is not very helpful when you are trying to work out how to minimize
the impact of deploying DNSSEC.

What I originally said was that I don't regard DNSSEC as appropriate for
intra-domain trust. What I did not say is 'broken'.

I think that a lot of the limitations people are finding in the DNSSEC model
come from the fact that in order to make the best use of information from
the DNSSEC it is necessary to have more information available to the client
than is available in a single request and response.

Once you have the ability to aggregate more information the value of DNSSEC
becomes much greater and the probability of providing protection in a real
world security context is much greater.

As you say, DNSSEC is currently just a tool. Now we have to work out how to
make best use of it.