Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

DNSSEC Implementation Held Up By Tech Delays

timothy posted more than 4 years ago | from the not-just-those-dogs-in-the-hallway dept.

The Internet 57

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."

cancel ×

57 comments

Trollin (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30120198)

Patrollin
Tryin to catch me terdin dirty

#GNAA irc.hardchats.com

First post (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30120284)

:-)

Can someone explain ZSK and KSK? (3, Insightful)

rsborg (111459) | more than 4 years ago | (#30120326)

Kane said that VeriSign will create and manage the zone-signing key (ZSK) for the root zone, and sign the root zone, for .net and .com. Icann will create, manage and publish the root zone key-signing key (KSK).

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).

Re:Can someone explain ZSK and KSK? (1)

TubeSteak (669689) | more than 4 years ago | (#30120542)

While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?
TFA does nothing to explain the nature of their problem.
Fairly useless as far as articles go.

Re:Can someone explain ZSK and KSK? (2, Informative)

vlm (69642) | more than 4 years ago | (#30120956)

While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?

Probably the agony of setting up precisely one zillion NSEC records makes the whole thing "unwieldy".

To properly return a cryptographically secure answer that there is no domain named silentdot.org, you need a line like:

shitdot.org NSEC slashdot.org

which is a pointer saying there is nothing between shitdot.org and slashdot.org.

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html [cisco.com]

Of course the only thing that is constant about DNSSEC, other than megatons of FUD, is constant change in how it works. Maybe NSEC is now as obsolete as MD and A6 records now are, I really don't know.

Re:Can someone explain ZSK and KSK? (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30121564)

So, what, 20 seconds of processing with a five line perl or gawk script is too daunting?

sort files (they already do this, so it can be done)
read files line by line (the already do this, so it can be done) and direct output to a script.

computer science 101, for chrissakes, this is baby shit.

Re:Can someone explain ZSK and KSK? (1)

hardaker (32597) | more than 4 years ago | (#30122612)

It frequently has to do not with just NSEC records but with memory requirements in general. Unfortunately, adding in all the crytographic hashes and NSEC records and keys tends to triple the memory requirements of a name server. Since versign and other folks would rather not publish a completely signed .com zone because of the added costs they're using NSEC3 instead which lets them skip publishing signatures for anything they don't want to. Thus there is very little cost change to them and they can still say "hey, we're super cool and have signed our zone now" but in reality they've signed only a small fraction of it.

As for NSEC going away, it's not likely. The root zone will be signed using NSEC as there is no reason not to since it's a public zone (there is no hidden data) and they want to sign every aspect of it (and it's small, so the cost isn't large). Other zones that don't have issues with privacy or with signing everything will likely use it too, as it's cheaper (CPU-wise especially) to actually deploy and use.

Re:Can someone explain ZSK and KSK? (0, Offtopic)

nine-times (778537) | more than 4 years ago | (#30121066)

I'm going to put IANAE in all of my posts here, since I don't really know what I'm talking about in any depth. However, my guess would be that DNS records, being small by themselves, are dramatically increased in size by adding encryption keys and signatures.

Re:Can someone explain ZSK and KSK? (1)

WuphonsReach (684551) | more than 4 years ago | (#30122530)

I'm going to put IANAE in all of my posts here, since I don't really know what I'm talking about in any depth. However, my guess would be that DNS records, being small by themselves, are dramatically increased in size by adding encryption keys and signatures.

Yah, a lot of DNS replies are really really tiny. As in under 64-128 bytes including packet header tiny. Just adding a 128/160/256 bit signature on top of the reply is going to bulk that up a fair amount. Plus you'll need the signing keys on top of that (another 2k to 4k bits).

It's really only going to be an issue for folks dealing with slow connections (under 64Kbps) as DNS lookups will take as much as an order of magnitude longer (but more like 2x).

(And I probably got a lot of details wrong as things change so fast. I'm sticking with educated SWAGs.)

Breaking DNSSEC talk by DJB (1)

js_sebastian (946118) | more than 4 years ago | (#30127898)

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 [cr.yp.to] .

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.

Re:Can someone explain ZSK and KSK? (1)

John Hasler (414242) | more than 4 years ago | (#30120566)

DNSSEC [wikipedia.org]

Re:Can someone explain ZSK and KSK? (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#30120610)

http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

Re:Can someone explain ZSK and KSK? (1)

nine-times (778537) | more than 4 years ago | (#30120778)

IANAE, but it sounds like the KSK is used to sign all the other keys to assure their validity. So you have a KSK for all of DNS, and you use that to sign ZSKs for each TLD...?

I don't really know, but it seemed like it might be more helpful to guess and let someone correct me than to just post a link to a long technical explanation.

Re:Can someone explain ZSK and KSK? (1)

cakefragment (1484945) | more than 4 years ago | (#30121620)

The KSK signs only DNSKEY records, and the ZSK signs all other relevant resource records in the zone. Your DNSSEC delegation comes from a DS record (a fingerprint of your KSK) which is included (and signed) in the delegating zone. The practical upshot of this is you can change your ZSK frequently without having to update the DS record upstream (thus contacting your delegator) every time you do so.

Re:Can someone explain ZSK and KSK? (1)

F.Ultra (1673484) | more than 4 years ago | (#30121630)

The KSK is the master key with which the various vendors ZSK keys are signed with. The ZSK key is then signing your key for domain.com This is so that the DNS-client does not have to have a long list of the various vendors keys as is the case with web browsers, all it needs to have is the KSK and with it it can verify the complete chain of certificates.

Re:Can someone explain ZSK and KSK? (1)

F.Ultra (1673484) | more than 4 years ago | (#30121704)

Wikipedia has some good info on this: DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust anchors.

* In order to allow for replacement keys, a key rollover scheme is required. Typically, this involves first rolling out new keys in new DNSKEY records, in addition to the existing old keys. Then, when it is safe to assume that the time to live values have caused the caching of old keys to have passed, these new keys can be used. Finally, when it is safe to assume that the caching of records using the old keys have expired, the old DNSKEY records can be deleted. This process is more complicated for things such as the keys to Trust Anchors, such as at the root, which may require an update of the operating system.

* Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are Key Signing Keys (KSK) which are used to sign other DNSKEY records and the DS records. Second, there are Zone Signing Keys (ZSK) which are used to sign RRSIG and NSEC/NSEC3 records. Since the ZSKs are under complete control and use by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection, but reducing the size of the RRSIG/NSEC/NSEC3 records.

* In order to help with key rollover, there are not only the normal DNS TTL values for caching purposes, but additional timestamps in RRSIG records to make sure they don't get used past the expiration of the corresponding DNSKEY records. Unlike TTL values which are relative to when the records were sent, the timestamps are absolute. This means that all security-aware DNS resolvers must have clocks that are fairly closely in sync, say to within a few minutes.

* The DS records in a zone's parent domain require the use of the zone's private keys and can only be created by the zone. They must then be transferred to the parent zone and published there. The DS records use a message digest of the KSK instead of the complete key in order to keep the size of the records small. This is critical for zones such as the .com domain, which are very large. The procedure to update DS keys in the parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be in the parent zone, also very important for large zones, such as the .com TLD.

Re:Can someone explain ZSK and KSK? (1)

hardaker (32597) | more than 4 years ago | (#30122498)

Because DNS tries to keep replies as small as possible for most of the data they introduced two types of keys into DNSSEC. One is a Zone Signing Key (ZSK) which signs all the data in a zone. The other is a Key Signing Key (KSK) which is used to sign just they keys in the zone (both ZSKs and KSKs are signed by it and the ZSK signs they keys too for that matter). This provides a number of benefits. Some people believe that ZSKs can be smaller and you can change them more frequently (on the order of every 1-6 months). Since the only one that signs these keys is the zone owner it's very easy to swap in a new ZSK (there are some timing issues involved, but there is no third-party communication that has to happen). Some people also use the fact that ZSKs can be easily replaced to treat them with a bit less protection security and key them online (required for dynamic DNS support) or in a less security containment system which lets them be used more easily and freely (e.g. for DNS zones that change frequently). The KSK only needs to be brought out when the signatures on the keys are expiring or the keys need changing. When you change a KSK, however, you typically need to inform your parent (e.g. .com) about the key change so that they can sign your new KSK (by signing a DS fingerprinting record). This is more of a pain, so people tend to only want to change KSKs on a infrequent basis (2-5 years is the common thinking).

Re:Can someone explain ZSK and KSK? (1)

klapaucjusz (1167407) | more than 4 years ago | (#30123500)

It means that VeriSign will be signing the zone, while Icann will be acting as a CA and certifying the keys used by VeriSign.

Dont worry about the Details, thes are Lies (1)

omb (759389) | more than 4 years ago | (#30124306)

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.

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 ... absolute nonsense.

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.

Re:Can someone explain ZSK and KSK? (1)

rs79 (71822) | more than 4 years ago | (#30132738)

Keep in mind they may be lying. We're supposed to believe with 10 years to work on this they're surprised that tha files are big? Uh, hello, no.

I suspect what's really going on is they just found the intellectual property gotcha inherant in DNSSEC that IMO is gonna prevent it from ever being widespread. It's as damning to the IP/TM guys as the Kaminsky was to technical correctness of the DNS and I suspect the project's been put on hold... and may not come back in its present form.

And then there's the .se debacle, and .de dropping off the net briefly last week.

Imagine a world without .com

uh (0)

Anonymous Coward | more than 4 years ago | (#30120392)

"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.

Re:uh (2, Insightful)

lbalbalba (526209) | more than 4 years ago | (#30120590)

Well, actually, I kinda sorta like it when the article summary's actually summarize the core concepts that there talking about.

Re:uh (1)

T-Ranger (10520) | more than 4 years ago | (#30121398)

What is this internet and telephone thing that its talking about? For that matter, what does "flaw" mean?

Re:uh (0)

Anonymous Coward | more than 4 years ago | (#30122652)

Ah yes, thank your T-Ranger for the typical nerd response. That showed him!

Re:uh (0)

Anonymous Coward | more than 4 years ago | (#30121446)

It's goddamn DNS. It doesn't need summarizing. Especially not with a stupid simile that you'd use to tell your grandparents about your job if you worked with it. Do you want Slashdot summaries to start including "a way for computers to talk to each other" every time they mention the Internet? Or "It's like sending a letter through the computer" every time they mention email?

Technical delays, Yeah Right. (2, Insightful)

lbalbalba (526209) | more than 4 years ago | (#30120430)

Unable or unwilling admins is more like it.

Re:Technical delays, Yeah Right. (3, Insightful)

Anonymous Coward | more than 4 years ago | (#30120794)

Yeah, Verisign, the largest certificate authority, is the organization responsible for implementing the feature of DNS that basically makes certificate authorities less necessary? I'm sure they're all over trying to get this done quickly.

I'd say unnecessary ... (1)

Pinky's Brain (1158667) | more than 4 years ago | (#30123026)

I trust DNS more than CAs ... just use the DNSSEC keys for SSL and be done with it.

Re:I'd say unnecessary ... (1)

TheRaven64 (641858) | more than 4 years ago | (#30127504)

They are meant to solve different problems. DNSSEC lets you tell that 216.34.181.45 definitely is the right IP address for slashdot.org (and, if you put a public key in a TXT record or similar, lets you establish a secure connection with this IP). A signed certificate lets you know that you are communicating with a domain owned by Sourceforge Inc. For most uses, the former is more important, but for things like Internet banking you also want the latter.

forward, stop or reverse (1)

SgtChaireBourne (457691) | more than 4 years ago | (#30121490)

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 [neowin.net] . 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 [venturebeat.com] . For the details of the 2008 flaw, not the x.509 cert flaw [techtarget.com] , Steve Friedl has An Illustrated Guide to the Kaminsky DNS Vulnerability [unixwiz.net] . 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.

Re:Technical delays, Yeah Right. (1)

F.Ultra (1673484) | more than 4 years ago | (#30121720)

I would say that the insane costs of a DNSSEC certificate is more probable as the reason...

Re:Technical delays, Yeah Right. (1)

WolfWithoutAClause (162946) | more than 4 years ago | (#30126454)

There was also a political argument about who should be the root signatory.

Since I would expect that the root signatory is able to forge DNS records for any part of the internet (or some such thing), it might be perhaps cynical of me to suggest that this wasn't entirely the simple prestige thing that everyone claimed it to be. ;-)

In a nutshell (0)

Anonymous Coward | more than 4 years ago | (#30120704)

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.

Why use digital signatures? (4, Interesting)

Myria (562655) | more than 4 years ago | (#30120708)

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.

Re:Why use digital signatures? (1)

MightyMartian (840721) | more than 4 years ago | (#30120868)

Wish I had mod points. An interesting solution.

Re:Why use digital signatures? (5, Informative)

Burdell (228580) | more than 4 years ago | (#30120998)

You should understand DNSSEC before criticizing it. It doesn't work with SSL-style certificates that have to be signed by a recognized certificate authority. Also, it doesn't change the existing protocol, it extends it in a (mostly) backwards-compatible way. DNS servers just have to know how to request and handle the new additional records; old servers and clients keep working fine.

Your proposed solutions only fix one small piece of the DNS problem, that of spoofed network packets. DNSSEC authenticates the entire response chain, so that (for example) you can be sure that your ISP isn't modifying responses to point you somewhere else (such as their servers) rather than what you requested.

With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to https://www.foo.com/ [foo.com] , you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).

Re:Why use digital signatures? (1)

dkf (304284) | more than 4 years ago | (#30128294)

With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to https://www.foo.com/ [foo.com] , you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).

That would only really work for the most basic type of signing, where the CA is asserting that the certificate is for SSL use on www.foo.com. I suppose the extended validation attributes (like the company's formal business identity) could also be done that way, but I doubt that ISPs are likely to want to get into that game (the liabilities from errors are a good reason to leave that with specialists).

For client certificates, a CA is really best. After all, I'm not a DNS entry, I'm a free man!

Re:Why use digital signatures? (0)

Anonymous Coward | more than 4 years ago | (#30121078)

These only protect against blind attacks. DNSSEC protects against an attacker who can view your traffic.

Re:Why use digital signatures? (0)

characterZer0 (138196) | more than 4 years ago | (#30121322)

Only if the answer does not change. If the answer changes, somebody who can view your traffic can replay old responses.

DNSCurve does not have this problem.

http://dnscurve.org/replays.html [dnscurve.org]

Re:Why use digital signatures? (0)

Anonymous Coward | more than 4 years ago | (#30122952)

Just an FYI, but replay would only be possible with DNSSEC until the signature expires. This could be awhile (a day, a week, a month, however the admin configured it), but on the other hand, how often to server IP addresses change?

Re:Why use digital signatures? (1)

Effugas (2378) | more than 4 years ago | (#30122984)

They can replay it within the absolute time of the RRSIG, which can be made relatively small (needs to be long enough to handle time drift).

Re:Why use digital signatures? (1)

omb (759389) | more than 4 years ago | (#30124506)

It is too late now, but you can always design a protocol to avoid, or negate replay attacks!

An interesting problem occurs in secure near real time system where avoidance is iffy but you still have time to negate,
think laptop plugged into an aircraft FBW, once remote piloting comes to Civil Aviation

Re:Why use digital signatures? (0)

Anonymous Coward | more than 4 years ago | (#30130336)

In all fairness, what is the risk with replay on DNSSEC? Let's say you know your server IP is going to change. You can change your signature expiration to something short. I think 60 secs is the minimum, but make it an hour. You move your server and resign your zone with the new IPs. Now an attacker can replay the old IP for an hour (or a minute or whatever you config'd).

For this to be of any use, the attacker would have to control the old IP (if he can route traffic regardless of the IP, you are hosed regardless of the DNS). So the attacker has the signature expiration length of time to get control of your old IP address and use it for nefarious purposes. I think the risk here is pretty small, and if you control the old IP during the change (I'm guessing this is the most common case), the risk is gone.

Re:Why use digital signatures? (2, Informative)

JesseMcDonald (536341) | more than 4 years ago | (#30121126)

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 see anything in the DNSSEC specs which would require any external chain-of-trust similar to the current CA system. You just need a secure way to update your resource records with your registrar, which includes your DS (designated signer) record, a public key of your choosing. There's no authentication involved beyond your credentials to update the domain. It's too early to be sure, but this should be included with the purchase of a domain. Once you have your DS record in place you can use it to designate signers for any subdomains.

You could even use it to sign a resource record containing your web server's public TLS key, which allows a real solution to the problem of encryption-only websites: a self-signed certificate which can be securely matched against the host domain, preventing the trivial MITM attacks which currently render such certificates useless. CA-signed certificates would still be useful for establishing real-world identity, of course.

Re:Why use digital signatures? (1)

tepples (727027) | more than 4 years ago | (#30123920)

You just need a secure way to update your resource records with your registrar, which includes your DS (designated signer) record, a public key of your choosing.

Watch registrars start charging for the privilege of serving DS records.

Re:Why use digital signatures? (1)

JesseMcDonald (536341) | more than 4 years ago | (#30124190)

They have to serve some sort of DS record for DNSSEC to work at all beyond second-level domains. They could withhold DNSSEC support entirely, of course, but the concept of using one's own DNS servers for third-level and lower domains, or at least having them hosted by someone other than the registrar, is fairly well entrenched. I just don't see them successfully reversing that pattern or forcing such domains to remain unsecured.

Re:Why use digital signatures? (1)

tepples (727027) | more than 4 years ago | (#30124516)

They could withhold DNSSEC support entirely, of course

Segmenting the market by withholding DNSSEC from customers on the $10 per year tier of domain registration is exactly what I meant, especially where VeriSign is involved.

Must use digital signatures? (1)

omb (759389) | more than 4 years ago | (#30124428)

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.

Re:Why use digital signatures? (1)

nine-times (778537) | more than 4 years ago | (#30121198)

I thought the idea was that all responses to DNS queries would be signed and therefore verifiable, and not that people would need to buy individual certificates from CAs.

Re:Why use digital signatures? (1)

Antibozo (410516) | more than 4 years ago | (#30122088)

That is the idea, but once you have that, it's fairly easy to replace x.509 certificates with DNS.

Re:Why use digital signatures? (1)

TheRaven64 (641858) | more than 4 years ago | (#30127542)

That is the idea. However, once you have DNS records that you can guarantee are authoritative, it's possible to store a key along with the address-to-name mapping. RFC 4025, for example, provides a way of putting IPSEC keys into DNS. These can then be used to establish an end-to-end encrypted connection at the IP layer so every packet sent to the IP looked up by the DNS query is encrypted. This eliminates most of the need for SSL on any protocol, because the connection is secured at a lower level.

CAs generally try to take this one step further and certify not only that you're connecting to the domain that you requested, but that the domain is owned by the right person or company. For example, when you go to paypal.com, you should get a thing saying 'PayPal Inc.' somewhere in your browser UI. DNSSEC + IPSEC does not provide this assurance (although, given the stories in recent years of how easy it is to get CAs like Verisign to sign fake requests, CAs don't really either).

Re:Why use digital signatures? (0)

Anonymous Coward | more than 4 years ago | (#30121314)

Your idea sounds similar to DNSCurve [wikipedia.org] , which solves a fundamentally different problem: it ensures that you really are communicating with the DNS server you think you are communicating with, but it does not ensure the DNS server is telling the truth.

Re:Why use digital signatures? (1)

amorsen (7485) | more than 4 years ago | (#30123852)

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.

DNSSEC, as originally conceived, did the exact opposite. Signing a zone was either-or, so the registrars couldn't charge each client for signing their records. Once you signed it for one client, you signed for them all. At the same time DNSSEC obsoletes SSL certificate authorities.

Now, if you happen to be Verisign and make a lot of money selling SSL certificates, how does that sound to you? A bit of work, no potential income from it, and destruction of a major part of your business...

This all lead to NSEC3, where you can sign each subdomain individually and thereby preserve the business model of charging each client.

Re:Why use digital signatures? (1)

Fastolfe (1470) | more than 4 years ago | (#30151612)

At the same time DNSSEC obsoletes SSL certificate authorities.

DNSSEC only allows authentication of a hostname. It's more useful to be able to authenticate a domain name with a real-world identity, however, which still (today) relies on trusted third parties signing certificates with those real-world identities.

This all lead to NSEC3, where you can sign each subdomain individually and thereby preserve the business model of charging each client.

??? NSEC3 is just an extension of NSEC (authenticated NXDOMAIN). It has nothing to do with signing subdomains. The whole signature delegation thing has been in DNSSEC since the beginning, since that's how you get from the root to the GTLDs, and from the GTLDs to the second-level domains. There's nothing special/magical/new about continuing that chain of delegation.

MoMoney (0)

Anonymous Coward | more than 4 years ago | (#30120834)

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.

Obligatory (1)

mac1235 (962716) | more than 4 years ago | (#30121496)

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...

"technical reasons" (1)

leto (8058) | more than 4 years ago | (#30121690)

Three years to deploy RFC 4956 [faqs.org] is not "technical reasons"

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...