Slashdot Mirror
DNSSEC Implementation Held Up By Tech Delays
Jack Spine writes "VeriSign has said that the main obstacle to DNSSEC implementation has been technical delays. The large size of the .com and .net domains would have made it impractical to deploy earlier versions of DNSSEC, according to VeriSign vice president of naming services Pat Kane. Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory. The problem of DNS cache poisoning was thrown into sharp relief by researcher Dan Kaminsky last year."
This is over my head, as the terminology seems repetitive (ZSK for root zone vs. root zone for KSK ?!?!)... can anyone explain the details to a DNSSEC initiate (A quick google search didn't yield any easily understandable content).
Make sure everyone's vote counts: Verified Voting
"Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory"
If you don't know what DNS is, why are you reading Slashdot? Go back to Digg.
Unable or unwilling admins is more like it.
In a nutshell, verisign will provide the keys for the root dns servers as well at the .com and .net gtld's (generic top level domains). It will be the responsibility of the Icann to publish the signing key to be used on the domain servers.
This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever. I don't feel that it's necessary to use digital signatures to secure the system.
The fundamental flaw of DNS is that the "nonce" - the one-time-use random constant used to prevent spoofing - is only 16 bits. If you're going to change the DNS protocol, why not just increase the size of that field to 64 bits and be done with it? Then it's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.
Also, I don't think that it's even necessary to change the protocol. The protocol allows for multiple DNS queries in one packet. When doing a DNS query, ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com. If the query comes back saying that eujrdyhtaeoym.example.com does not exist (or even if it says it does!), you know nobody is spoofing DNS queries back at you because unless they were snooping traffic, they wouldn't have a way to know that your nonce was eujrdyhtaeoym.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Hmm... sounds like just another way for Verisign to add to their bottom line by making everyone purchase additional signed certificates for their DNS servers.
Unable or unwilling admins is more like it.
A side effect of buying into the so-simple a monkey could run it sales pitch from Microsoft: You end up with monkeys that can only stroke the big boss telling him or her to sit tight till the next free t-shirt^H^H^H^H^H^H^H service pack. As these monkeys are able to bullshit their way into training positions, they will do what any other weak or insecure monkey will do: bogart their already limited knowledge. Thus with each iteration you get progressively more ignorant monkeys, that have to rely and specialize more and more in social engineering and keeping the managers away from real it staff to keep their jobs. That same level of skill and knowledge permeate that one vendor's products and services. When the products or services get enough bad press, they just rename them. Enough of that though.
There are some good interviews about the DNS flaw, like the one at Black Hat. For the details of the 2008 flaw, not the x.509 cert flaw, Steve Friedl has An Illustrated Guide to the Kaminsky DNS Vulnerability. If you played with DNS during 2006 or 2007 you probably at least spotted symptoms of the flaw as it seemed to be in growing use.
Frustratingly, the solution has been there in front of us for many years and most systems have been more than capable of deploying DNSSEC, either as part of IPv4 or IPv6, for many years. Except for one vendor that can't. Take a guess which one. Take a guess how much it has cost us to let them hold back the net.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Young whipper-snappers! Back when I wanted a secure DNS server, I had to use djbdns! And this was before it was it was open-sourced, no apt-get or rpm -i for me. Why back in my days, you had to set your IP address yourself, none of this new-fangled DHCP.... mutter mutter Arcnet! mutter...
Three years to deploy RFC 4956 is not "technical reasons"
I trust DNS more than CAs ... just use the DNSSEC keys for SSL and be done with it.
This is typical Marketeer speak and crap. The existing DNS is data driven, via the Zone files for each (group) of Domains, the basic problem is that contrary to the small, simple friendly days of the arpa net, the distributed nature of the existing network of DNS servers is easily subverted by servers who deliberately lie in answer to DNS queries.
... absolute nonsense.
The solution is well understood, use cryptographic signing, with a known Public Key, so that clients can verify that the answer they get is Genuine Signed. This would be simple if we only had a few zones, and the root could sign all of them, we don't we have zillions so, to prevent changes becomming an impossible bottleneck we need a heirachy of keys so that, when I the admin of a zone, edit the zone I can sign the changed entries with the private key for that zone. The way DNSSEC is designed this turns the problem into one of private key authentication, management and distribution. A bit trickey, but really not that hard.
What Verisign are setting you up for is this is a HUGE problem so signed zones are going to cost a lot of MONEY.
The greed and averice if the potential Certificate issuers (yes I am looking at Verisign) and its interaction with OS and Browser vendors is the main reason the internet is not secure, and this way of working dosn't scale and isn't agile.
Certificates need to be nearly free 1 CHF, 1 USD, 1 GBP, 1 EUR each, and you need to be able to generate your own and have it signed, semi automatically, by your government, and everyone should be issued with a personal certificate, at birth, free. On a CD or something. All the Bolony of investigating who you are before issuing the Certificate is self serving and expensive Crap. It only benefits the technical registrars and needs to go away.
Verisign are telling us that they need a year, at least to convert a 50m row database
Finally, given all the nonsense on the other side let me tell you about Self Signed certificates; I deal with maybe 20 organizations where I really care about the risks of a MITM attack or being able to Digitally Sign things, and if there was a Public Registrar, that would be the 21st, and I have a complex, multi national digital life, so most people need less but I cannot see anybody needing > 100. You can manage this manually.
If I do business with you all I need to do is give you a copy of my Public key, and a printed paper with the key-signature, when I sign something you check my public key signature, decrypt the document and verify the hash, if it is all OK you can trust it. If you want to look pretty you can use smart cards, but you can also use paper and the telephone. Even with an MD5 digest you have about three times the domestic security for a Swiss Bank.
As computers/algorithms get faster quick hacks fail ever sooner.
Ther is little wrong with the design of DNSSEC except it allows --- FOR MONEY --- trust vendors a completely unrequired role in the system, DNSSEC could have easliy avoided this but this is a political question, you should provide your public key, self signed or not, and that needs basically to be the end of it. I can now advertise the fingerprint of my public key on my business card or signature.
While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?
DJB held an interesting keynote at USENIX WOOT this year, on some of the unintended side-effects of DNSSEC. Here are the slides: http://cr.yp.to/talks/2009.08.10/slides.pdf.
The biggest issue he found was that the a single, small DNS request triggers a huge DNSSEC response with lots of digital signatures (each one of which is at least 1024 bits...). Since the requests are sent over UDP, they can be spoofed. End result? a HUGE DOS amplification effect.