Matasano Chargen - Latest Comments in A Case Against DNSSEC (A Matasano Miniseries)

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Sat, 12 Jul 2008 00:45:34 -0000

Because you can try IPSEC out on your VPN without screwing anything else up. But to deploy DNSSEC, we have to forklift it in to the DNS hierarchy.

Re: A Case Against DNSSEC (A Matasano Miniseries)

ps — Sat, 12 Jul 2008 00:43:47 -0000

A few things that stand out here --
- DNSSEC is way past its need-by time.
- It will be an addition that very few applications/services use/require.
- Companies will try to market their crappy products on the back of DNSSEC.

But if they could find a good use case for IPSec (VPN) then why not see what happens with DNSSEC? I agree that it is totally redundant and that any problem could be solved without using DNSSEC.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Peter — Fri, 11 Jul 2008 10:16:59 -0000

Here's the paragraph I disagree with:

DNSSEC gets in the way. It distracts us from real problems that need to get solved. It also substitutes a bunch of IETF people for the judgement and expertise of the market, which actually has a track record in solving security problems. Some of the loudest IETF participants have no qualifications other than willingness to spend time on mailing lists and at conferences.

1. Most security staff make a point of being distracted from solving real problems. If it wasn't DNSSEC it would be something else.
2. The security market is ineffective - see the economics and security literature.
3. Arguments need to be judged by something better than loudness.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Wed, 09 Jul 2008 00:14:31 -0000

Brad: why are we overhauling the DNS to create an IETF/IANA-owned PKI? What makes you think there's one PKI design that will solve most applications problems? And how much credibility does DNSSEC have at this point as the vehicle for solving those problems?

Re: A Case Against DNSSEC (A Matasano Miniseries)

Brad Knowles — Tue, 08 Jul 2008 17:49:13 -0000

Thomas -- the cost of SSL/TLS is not the money to get the certificate. The cost is the transactional overhead of doing the crypto and setting up the connection.

I'd like to see you do 15,000-25,000 SSL-enabled web transactions per second on a single machine with just one CPU. I've seen nameservers that can do that many authoritative queries per second. Add SSL/TLS to that mix, and the number will drop -- by orders of magnitude.

And many of the most important nameservers are already vastly overloaded by the crap they've got to deal with today.

Personally, I think we can solve a lot of the DNS security issues by simply requiring (and enforcing) good administrative principles whereby we enforce a separation between the authoritative and caching-only functions, and we carefully vette the incoming traffic to only allow those types of queries and transactions that we know to be "safe".

DNSSEC is useful and serves a purpose, but I don't think that cache poisoning/pollution and phishing are the right problems to be trying to use it to solve. Those can be solved in other ways, leaving us to use DNSSEC to solve harder problems in other areas.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Richard Kay — Sat, 14 Apr 2007 06:27:41 -0000

The point I'm making is that DNS as it stands is adequate for the kind of directory service that it is currently used for but this stretches to meet the requirements when money is involved to the point were monetary transactions are much more expensive than they need to be. This in turn causes a drag on the whole economy and slows the digitisation of money as a whole system. It's a bit like a telecom last mile problem. Currently digital cash and the new forms of currency this makes possible cost too much to do the accounting for this to be viable in many applications.

With DNSSEC it becomes possible to design directories which are secure enough to be used for monetary identities for everyone - not just merchants who can jump through all the hoops currently involved in setting up a merchant account.

This is because with DNSSEC the certificates will delegate through the domain registration process. If the syntax differs between
my_account_number@example.bank and my_account_number.example.bank the semantics don't as example.bank obtains it's certificate from the .bank TLD key and my_account_number obtains its certificate from example.bank . The syntax and semantics of the certificate chain are crucial if there is any possibility of identity being misread i.e. phishing. Also we can expect the .bank TLD to be a lot more careful about certification than .com , and consequently it's certificates will be trusted to a much greater extent and rightly so.

So I think that DNSSEC does solve a genuine problem, though the cost of it doesn't justify being applied to applications that don't need it, until the development cost has been carried by those that do to the point where scale and further technical development makes DNSSEC cheap enough to improve other directory applications.

I'm going to be away from the Net for a week but will check back then.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Fri, 13 Apr 2007 00:27:10 -0000

I don't get it. What's the cost of an SSL/TLS transaction? You realize the CA's don't charge *per connection*, right?

Even having said that: if CA's charging $30 for BER bits bugs you --- and it bugs me too --- then the problem to solve is getting a trusted, secure "public" CA. That's not a technical problem.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Richard Kay — Thu, 12 Apr 2007 13:21:23 -0000

If DNS were just a directory of Internet hosts the argument given above against DNSSEC would be valid. But DNS already supports directories of many more things than hosts, e.g. email reputation lists, organisation address lists and phone books.

The need for DNSSEC and all its relative complexity arises when we start considering Internet support at lower levels of layering for the kind of message we call money in all its potential forms, with DNSSEC directly providing the kind of directory we call bank and payment accounts so that a future payment can be routed between the correct accounts. Here the cost of doing this directly supported by DNSSEC will potentially be much less than the current cost of an online Visa or Paypal transaction supported by TLS/SSL and all the traditional banking protocols that sit on top and which typically cost merchants 6% of the transaction value and which are not economical for payments of less than $5.

In my understanding it is possible to get this cost down to the point where every payment of a bus fare or supermarket coupon is an almost zero cost Internet message. The main cost of this will become the manual effort of checking your monthly statement, which getting everything online will help you to automate to an extent. However, this requires a more inherently secure directory than DNS in its current form.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Wed, 04 Apr 2007 08:31:37 -0000

They can also choose not to use IP. Why are you being evasive?

Re: A Case Against DNSSEC (A Matasano Miniseries)

Jay Daley — Wed, 04 Apr 2007 03:31:56 -0000

An application developer can choose not to use DNS. They cannot choose whether or not to use a routing protocol if that is implemented on their network path somewhere.

Re: A Case Against DNSSEC (A Matasano Miniseries)

ivan — Tue, 03 Apr 2007 23:54:28 -0000

RFC1123: Requirements for Internet Hosts - Application and Support lists DNS requirements as part of support services (not as an application) and it specifically says that every host MUST implement a resolver and MUST use it to convert hostnames to IP addresses. Therefore, if every host on the Internet MUST rely on the DNS system for host name resolution, it is evident (at least to me) that the DNS system is part of the Internet infrastructure.

Disregarding the RFC and how the IETF may think about this, my test to determine if X is infrastructure or not is simple and maybe a bit naive, I ask myself: does the Internet work without X? If the answer is no then X is part of the infrastructure otherwise X is not part of the infrastructure.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 18:55:54 -0000

Except Dan Kaminsky.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 18:55:27 -0000

I mean less offense than it sounds like I do. I just find the distinction you're making totally artificial. Applications are things people overtly use. Nobody overtly uses DNS.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 18:54:33 -0000

So, by your take, MBONE "wb" is an infrastructure tool, but BitTorrent is an application. Good test!

Re: A Case Against DNSSEC (A Matasano Miniseries)

Jay Daley — Tue, 03 Apr 2007 18:50:19 -0000

By 'router' and 'end computer' I mean the functions they are used for, not whether they come with a GUI or an Intel-inside badge. That's why I used the term 'end computer'.

When someone writes an application they use gethostbyname or the equivalent. So DNS is not transparent to them. Routing protocols like RIP are entirely transparent unless they are writing network specific applications.

The test works pretty well.

On the P2P side my point was that any P2P app that wants to be free of DNS /must/ do two things
- its own name resolution
- its own non-DNS bootstrap

Yes some apps do the first but almost none do the second. So they do rely on DNS somewhere.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 18:18:56 -0000

With regard to "who's going to go through the trouble of using an alternate name service instead of DNS", I offer as counterexamples every IM protocol in current use, every P2P protocol in current use, and Google.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 18:18:00 -0000

Jay: your acid test for "infrastructure" vs. "application" breaks for route servers and any network more than 7 years old. There's a reason BSD ships with "routed" --- people actually used it.

Can you take another cut at what differentiates "infrastructure" from "application"? You've put DHCP firmly in the "application" category. Also, ARP.

It's obviously not "computer" vs. "router".

Maybe it's "desktop" vs. "server"? I totally buy that. Of course, that leaves DNS in the infrastructure.

Either way it seems pretty obvious to me that DNS is not an application. In that nobody sits down to "use" DNS.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Jay Daley — Tue, 03 Apr 2007 17:46:02 -0000

Jon

Nobody is saying that applications should leave security to DNSSEC. Also nobody is sayin that DNSSEC verifies endpoint security. All it does, as you should expect, is secure DNS.

Host file entries don't need validating because you put them there. DNSSEC is about securing messages you receive from other people.

All DNSSEC does is let you verify that the DNS data you receive is the DNS data that was sent to you. It makes no assertions about the endpoints.

On the P2P point:

OK, with some effort you can avoid the direct use of DNS entirely. You can write your own name resolution protocol and to bootstrap the network discovery you can define some well known IP addresses in your application and ensure they always respond.

But seriously though, who is going to go to all that trouble? The name resolution side, sure some people do that, but the bootstrap as well?

I was wrong to say that people can't write P2P without DNS. It is more correct to say that people /don't/ write P2P without DNS.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Jay Daley — Tue, 03 Apr 2007 17:23:19 -0000

I'm surprised that you resort to inventing something to attack in order to defend your position. As it happens, I've never written an RFC and only occasionally post to IETF mailing list. Not realy the IETF person you seem to want to demonise.

Anyway, back to the technology:

It's easy enough to tell the difference between an application and infrastructure. Does it normally run on a router on an end computer. That's why the routing protocols you list are infrastructure and DNS is an application.

You even say yourself that people use DNS as a building block for applications - more proof that it is an application. The only applications that are built using RIP, OSPF etc are specialist network applications. To all other applications they are completely invisible - a sign of true infrastructure.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Matt — Tue, 03 Apr 2007 15:47:44 -0000

Of course, I feel compelled to mention that Dan Kaminsky's solution to getting secure DNS lookups is to proxy them to a trusted network over an SSH tunnel... which of course is running on top of DNS. I believe his line at this point is "Malkovich Malkovich Malkovich."

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 13:45:58 -0000

Scary sidenote: Dan Kaminsky does use DNS browsers to send DNS mail about the DNS files he streams through DNStube.

Re: A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek — Tue, 03 Apr 2007 13:45:22 -0000

I tried to call my mom to ask about babysitting this week but she was too busy using her DNS browser to send DNS email about the DNS files she was sending to stream through DNStube.

And yes, the emotion I'm trying to evoke with "IETF people instead of the market" and arguing whether DNS is an application is, "profound, unpleasant concern".

About 7 years ago I started a company with Dave Meltzer and Danny Dulai doing streaming media delivery over a multicast-routed overlay network. A couple other companies did it better (like FastForward) and we got crushed, but I got to pay attention to what people said to them: "you can't do multicast at the application layer! It's a gross layering violation!".

I'm really bothered by the thought that the IETF is populated by people who think that the OSI model --- again, O S I, people --- is the Talmudic kernel of protocol design. So that something is an "application" if it uses BSD DGRAM sockets to communicate, but "infrastructure" if it's hooked up directly to software interrupts in the kernel.

Leave aside the notion that the OSI model doesn't capture the Internet stack well: if you divide the world up into "transport, infrastructure, and applications", "infrastructure" is "anything you build on AND never use by itself". DNS is infrastructure. You could replace it and, as long as you didn't break libresolve and whatever the hell Win32 uses, nobody would *ever* notice. Just like I don't care how you reinforce the concrete in my building but I do care about how my desk is built. Infrastructure, applications. NOT HARD.

I feel bad being a dick about this because Mark Andrews took the time to write a polite response, without evoking the "I'm from the IETF, and what RFCs have YOU written" sentiment that Jay did. Mark is clearly more important than Jay and I'm casting aspersions on both of them. Oh well, omelettes, broken eggs.

Re: A Case Against DNSSEC (A Matasano Miniseries)

John McDonald — Tue, 03 Apr 2007 10:32:30 -0000

Nah, I'm sure we'd understand what he means if it wasn't for our limited technical skills. :>

Re: A Case Against DNSSEC (A Matasano Miniseries)

Jon Bowie — Tue, 03 Apr 2007 10:24:42 -0000

On a side note, should it bother us that there are people working for a domain registry that think DNS is an application?

Re: A Case Against DNSSEC (A Matasano Miniseries)

Jon Bowie — Tue, 03 Apr 2007 10:15:09 -0000

A Different Case Against DNSSEC:

http://securitytracker.com/alerts/2007/Jan/1017...
http://cve.mitre.org/cgi-bin/cvename.cgi?name=C...
http://xforce.iss.net/xforce/xfdb/28745
http://www.securityfocus.com/bid/22231/discuss

Wasn't I just making the point like a week ago that security extensions shouldn't be re-engineered into protocols unless a) they reduce the attack surface of its implementations, not increase it and b) the circumvention of the security mechanism outweighs the practicality of exploiting it.

Interesting that one of those advisories is an SSL advisory. Oh, wait, that's right they're using SSL to handle the RSA key negotiations. Oops. So now not only are our web architectures having their attack surface increased by being reliant on the successful implementation of supplemental security extensions, but now we want DNS implementations to be as well.

Isn't the fundemental rule of secure development that you want to give the attacker the fewest possible exposed points of failure to exploit?

Tom makes at least 3 excellent points is this post:

1) PEBKAC: We have SSL certificates to authenticate web sites, if end users are already falling for accepting bad SSL certs supplied by a MITM; what makes you think they won't accept similar bad DNS messages supplied by a MITM.

2) Infrastructure is not where you fix problems that exist in the implementation of application layer services: Application developers shouldn't be so lazy as to force their applications to implicitly trust DNS information. gethostbyname() isn't something to build a host-based authentication system around, nor should it be.

3) Ends don't justify the means: You go through all the effort of generating RSA keys for all of your DNS servers, then you have to inform the underlying resolution architecture on all the platforms you have deployed what the trusted servers are. After all this, you still haven't prevented localized DNS tampering. What about local HOST file resolution? Is that just going to go away? Are we going to start validating host file entries via DNS... Doesn't that defeat the purpose of having them? If all of these attack vectors are maintained, where was the value add of building DNSSEC into the architecture?

My take on the solution to this problem is this:

If you need a cryptographic solution for verifying endpoint authenticity, don't use DNS. Use SSL, and and a private CA for issuing certs to clients with validated credentials, it's what it was designed to do. Don't try to build a cryptographic extension into an already insecurely designed protocol. It's like Adam Sandler throwing the newspaper on the pile of puke in 'Big Daddy'.

I'd also like Jay to explain to me why P2P networks need DNS... Is he insinuating that it's not possible to architect a P2P network without using DNS, that seems a bit naive.