Swing! And A Miss On DNSSEC At eWeek

Thomas Ptacek | August 22nd, 2007 | Filed Under: Bitching About Protocols

Larry Seltzer, writing in his column:

Of course, as Aitchison says, even that third party is accessed through domain names. If I’m spoofing DNS, what’s to stop me from spoofing verisign.com and putting up my own fake certificate authority?

Of course, what stops you from erecting your own CA is that you can’t recover the prime factors of very large numbers (or pretend to), or if you can, you have better things to do with your time than set up phishing sites. Like winning a Fields medal.

In other words: your browser shipped with Verisign’s key. You never trusted the (insecure) DNS to get it. Neither did you trust:

  • the (insecure) DHCP protocol, which told you your router’s address, or

  • the (insecure) ARP protocol, which told you how to reach that address, or

  • the (insecure) OSPF routing protocol, which told your ISP’s network where to send the packets you handed your router, or

  • the (insecure) BGP interdomain routing protocol, which, but for a carefully-crafted regex string, allowed any network in the world to claim the destination address of those packets.

Because of any of these failed, you’d be in the same pickle, DNSSEC or not.

… it’s like, I don’t even care if the DNS is secure.

Viewing 7 Comments

    • ^
    • v
    Wow.

    "Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983..."

    ... and still doesn't know how SSL works.

    That has to be embarrassing.
    • ^
    • v
    DHCP and ARP can be secured with DHCP Snooping and Dynamic Arp Inspection (DAI). There were a few Cisco Press books which have covered this in the past, but none as complete as LAN Switch Security: What Hackers Know About Your Switches, which I read yesterday on SafariBooksOnline.

    OSPF can be secured with keys, MD5 authentication is popular here - but there are surely other options including IPSec. It often helps to configure neighbors and interfaces very explicitly as well.

    BGP is the same as OSPF - and does have other issues which are usually properly addressed by major ISPs. The IETF SIDR WG and DHS SPRI have made some improvements, but I'm even more impressed by the BTSH hack from Vijay Gill, as well as the prefix filter work by Bill Woodcock.

    I'm not sure if DNS can be secured in similar ways, although I guess that's what DNSSEC is all about (or is it?). Interestingly enough, I figure you could also wrap DNS in SSL and make it more secure. For example, using SSLExplorer as an SSL VPN without leaking any packets at Starbucks. Otherwise Dave Maynor will steal your GMail cookies and call it "Web 2.0wnage".

    SSL does provide everything that you'd want in a secure protocol, but it's always nice to cater to the lowest common denominator. For example, imagine if Dave Maynor clones himself and parks at every Starbucks with a stolen MBP. With all of the websites not using SSL, plus the lack of business and casual Internet users unaware of SSL VPN technology - Dave could hold the world hostage by preventing anyone from using webmail, myspace, and youtube.

    Circa 1997 (when WiFi didn't exist just like hubs don't exist today), it appeared that the correct answer would have been DNSSEC with DAI on a wired network that does not allow sniffing. SSLifying everything was nearly impossible because of the costs involved. I can see how some of these DNSSEC guys came to the wrong conclusions... as moronic as they are...

    Is the cost of SSL still too high? Could webmail and myspace be SSL only (with proper HTTP to SSL redirection)? Is Tor a better answer because of the way that exit-nodes work? Do we even care about webmail and myspace? Is there a more optimal solution?

    Hear me out here: maybe SSL isn't the best solution to all the problems we are trying to solve with regards to network-based MITM. Maybe we need a different solution. Curphey (yes, I know, I always quote Curphey these days and then provide a link to his blog) recently reviewed a interesting product for a VC firm. Side-note: sounds like a cool job.

    The product took the whole "SFTP vs. SSL FTP vs. SCP vs. FTP with GPG encrypted files" problem and flipped the script (i.e. hs\nib\!#) on it. I've seen this problem at many companies before. You have two companies who can't send files to each other because one only likes SSH and the other only likes SSL FTP. So this company Curphey reviewed created a dynamic application that uses S/MIME over email to send files through their product app (hopefully it's a cross-platform application). In other words, it caters to idiots.

    SSL and PKI are not as idiot-proof as IBE, as a good example of evolution and innovation. While DNSSEC may be going backwards in time, I'd like to know what's on the horizon.
    • ^
    • v
    That's all good to know, but none of what you just described is actually used in any network we've worked on. The only infrastructure protocol we're talking about that has anything even close to real defenses is BGP, and that's obviously all duct tape and baling wire.

    Maybe SSL isn't the solution for everything (though it's certainly the solution for most of the web security problem). But what's a problem for which securing only the domain name lookup is a good answer? And what's a problem for which you secure the rest of the transport where you're still left needing to secure the domain name lookup?
    • ^
    • v
    But what’s a problem for which securing only the domain name lookup is a good answer? And what’s a problem for which you secure the rest of the transport where you’re still left needing to secure the domain name lookup?

    Updates that occur over the network for legacy OSes and applications that do not already have SSL or signature checking built-in.

    That's all I could come up with. It's not much and it's not exciting, but it may be useful for places who still are stuck in 1997 and have adversaries targeting these particular hot-points. Remember the worms that targeted windowsupdate.com? I'm not sure that there was ever a military or war strategy (outside of StarCraft) that involved killing all the medics first (or bombing the first-aid supply chain) - but you should never underestimate these chicken/egg problems.
    • ^
    • v
    So then you agree that rearchitecting the entire DNS and adding key expiration and rollover to the mix is lunacy.
    • ^
    • v
    I like the idea that protocols have security built-in (RFC 3365). DNS does not have security built-in, thus lowering the security and trust-models of systems that depend on it.

    Does DNS need security built-in? Yes, eventually. Should DNS be replaced? Yes, eventually. Should applications depend on DNS for trust? Absolutely not (but some still do). Should they trust properly implemented SSL instead? Hell yes!

    Is DNSSEC worthwhile in 2007? If you have to ask yourself that question, maybe you should consider other more interesting or important areas of research.

    Tom, maybe your problem is that you don't understand what it's like to only know one thing well for many years, have that one true skill, and then not be able to use it just because it's a completely useless skill that solves part of a problem that should have been easily/completely solved tens of years ago. We should let these guys do their thing if it makes them happy. It may end us helping us slightly in the long run. One more check box for compliance. Ahem *clears*throat*. I meant uh... security. Yeah.
    • ^
    • v
    Notice how I said "It may end us". I think that was supposed to be a typo, but I'm not so sure now

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus