Experts Tell Feds To Sign the DNS Root ASAP
alphadogg sends along news that the US National Telecommunications and Information Administration has gotten plenty of feedback on its call for comments on securing the root zone using DNSSEC. The comment period closed yesterday, and more than 30 network and security experts urged the NTIA to implement DNSSEC stat. There were a couple of dissenting voices and a couple of trolls.
(Satan unpacking his sno-cone machine)
"'Bout damn time I got to use this thing..."
...something with an uncommon opinion. In my experience, the trolls are usually right.
-=/\- Jizzbug -/\=-
Is DNSSEC ready for prime time?
Last I checked (admittedly more than a year ago), they were still working on a good way of refreshing the key; there were also other problems with DNSSEC that made it not quite ready for prime time.
Does anyone know if the people involved have all said "Yep, it's done now, go use it"?
It'd suck to be in the IPv4 situation: there's this thing we want to migrate to as soon as everyone else does as well.
It's easy to say "let's try out some shit and drop it if it doesn't work" when very few people grow dependent on your work; when the whole world does so, it's a bit more difficult.
With a conventional PKI for your SSL certificates, Verisign or the other CA gets a cut for EVERY server.
With DNSSEC, the "CA" only gets a cut per domain. Thus DNSSEC can be used to offer key distribution with far less cost, once the root and the TLDs start signing records.
(Not an original argument, but I agree with it.)
Test your net with Netalyzr
Are you troubled by DNS cache poisoning...well don't worry!
I wrote a song about it!
Your domain will be safe,
You'll be well on your way
With DNS-SEC security!
Signing is a breeze,
Bring hackers to their knees
With DNS-SEC security!
I know you're grown attached to old
Ways of doing things
But when you update BIND
Your heart will race to sing!
DNS-SEC implementation
Put the spammers on permanent vacation
DNS-SEC implementation
I hear it's got great documentation!
Bind me, baby!
(GUITAR SOLO)
(-1, Raw and Uncut is the only way to read)
I wouldn't be so quick brush aside dissension on this issue. This comment in particular:
http://www.ntia.doc.gov/DNS/comments/comment034.pdf
seemed well thought out, and at the end suggests several other workarounds with fewer issues. Namely, switch to using TCP instead of UDP so there's a handshake involved instead of blindly accepting incoming datagrams. It's not that the bug shouldn't be addressed, but maybe DNSSEC is the wrong answer.
It's funny how a regulated DNS still has so many security problems. I wonder if a distributed, non-governmental DNS that used a web of trust / trust ratings would work better for domain resolution.
-- http://ninthagenda.com/
For those of us who trust that this is something that matters, but aren't nerdy enough to understand. What is the problem that the experts were being consulted about?
Congratulation! You've just explained why the DNSSEC will never be implemented on the root server.
May the Maths Be with you!
| Administration has gotten plenty of feedback
WTF?
try "received"
Administration has received plenty of feedback
Much better.
...over ubiquitous use of SSL?
Almost all of the extra overhead for crypto and/or signing is in processing the initial public key. So DNSSEC seems to make our systems work about as hard, without the benefit of encrypted data.
OTOH, having an Internet trend set in with most servers switching to SSL (i.e. HTTPS, etc) keeps the government (and corps providing its "security" snooping services) from profiling people based on their everyday choices of art, books, and ways of socializing. It takes ISPs out of the loop as far as acting as surrogate cops snooping on peoples' data.
If I wanted to further a police surveillance state, I would try to set a trend with DNSSEC instead of a different public key scheme that provides encryption along with verification for the same price... especially if the tools to implement the latter were already on everyone's system waiting to be fully used.
Uh it's just a way for CAs to make money _twice_ (or more times).
;) ), and yet people _will_ leave the Verisign root certs in - because all you care is you don't that get warning.
:).
You'll still need CAs.
How does DNSSEC stop the browser from giving Joe User a warning box that the https cert is not signed by a recognized CA?
That's the only real reason why you pay CAs to sign your certs - to stop Joe User from being bothered it.
That CA signing bullshit is little to do with security. Because the last I checked:
1) nobody really goes through all the CAs bundled with their browser and says: "Yes I trust this CA, no I don't so I'll delete this". There are tons, do you know who they are and how trustworthy they really are? Do you really care? No all you care is that you don't get that warning.
2) Verisign has proven that they voluntarily do dubious stuff and they've even misissued Microsoft certs (go look under Untrusted Publishers in IE's list of certs
3) Do browser makers actually remove CAs who don't comply to some standard? Do they even have some meaningful standard in terms of security?
4) AFAIK browsers don't warn you if the a valid cert changes to a different valid cert (even if it is signed by a different CA).
As you can see, they're not really safer than self-signed certs. To me browsers should do that SSH thing and warn you if the cert has changed (whether it's self-signed or CA signed).
In that light, forgive me if I'm not convinced that DNSSEC is really going to make things more secure
It'll just be more of the same. One more way for Verisign and gang to make money for making people feel safe.
Its not really what you say that makes you a troll( in this case), but how you say it, in this case. That comment isn't wrong, but its not using appropriate language for the forum. If he had just said something like "Verisign has repeatedly acted to maximize its short term profits at the expense, and against the interests of the general internet community. Therefore I feel it would be unwise to give them this additional responsibility."
Well.. maybe. Or Maybe not. But Definitely not sort of.
I tend to agree.
Bind me, baby!
The S in S&M does not stand for Security.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
I love beating this dead horse: OpenPGP is the one scheme that authentication right, and DNS is Yet Another great example where OpenPGP should be used instead of the obsolete X.509.
Why would I trust the feds as an introducer? We already know that they do attempt MitMs sometimes, and there's already a history of DNS abuses ordered by presumably well-intentioned courts. But even if this organization had a good reputation, it's just plain dumb to put all your eggs in one basket. There should be provisions multiple certifiers of an identity, so that users decide who is trustworthy and who isn't.
If the feds are going to sign, I hope they use an OpenPGP signature (which apparently the spec allows!), but I somehow doubt they would want to lend any legitimacy to a scheme that actually lets people authenticate identities, instead of the one intended to create monopolies and single points of failure.
I have no problem with the feds helping out on this, but we shouldn't completely trust them, and we have the technology so that we don't have to. PRZ gave it to us a couple decades ago.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Let everyone be in charge of their own keys. There doesn't need to be a key. We can have Verisign do this and the feds and you and me.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I don't see why any nameserver (especially the root nameservers) could not carry signatures from multiple CAs. Maybe that's not DNSSEC (I can't be bothered to read the RFCs !) but it's certainly a technical possibility.
Also, I think any device looking up any DNS record can chose to ignore the signatures if it wants to anyway (most will).
So I fail to see what all the conspiracy issues are surrounding the signature of the root name servers. It seems a far cry from implementing a system to roll dnssec out to every nameserver and if a better solution comes along later, or DNSSEC gets better, the new ideas can probably get bolted on.
Nullius in verba
On behalf of the Association of Spammers, Scammers, and Dirty Crooks, they respectively vote no on strengthening our nation's DNS services.
I dunno about that... Most of them voted to renew that patriot act....
That is how Frankenstein's monster got his head, it was bolted on later as an afterthought. And man was it an ugly hack!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
... until they've showed it to their lawyer.
"I can't imagine how things could get any worse!" (some guy) "That could just be failure of imaginatioÂn on your p
With a conventional PKI for your SSL certificates, Verisign or the other CA gets a cut for EVERY server.
With DNSSEC, the "CA" only gets a cut per domain. Thus DNSSEC can be used to offer key distribution with far less cost, once the root and the TLDs start signing records
OK, I give up. What's EVERY an acronym for, again?
I was at a talk some time ago where people who run several european root domains were discussing the issue and all seemed to agree that TCP is not an option because it would greatly increase their load.
That said, I don't know how DNSSEC would be any more light on the CPU... I don't know the details but I assume you would have to sign every DNS packet that you send...
Shamir's algorithm is very clever. And cleverness is in short supply these days, especially in the dns.
I'm just thinking out loud here, but it seems to me if the source of authority field in the SOA statement were an IP and not a domain name, and each nameserver had a txt record with part of the zone maintainer signtaure of the whole zone that might work better than DNSSEC. Am I missing something here?
You'd have to change nameserver code but it's all gonna have to change anyway. Abd Bernstein said he's not gonna add something as stupid as DNSSEC to djbsns, which you'll note doesn't have the problem trying to be solved here in the first place.
Bind and the industry's insistance on superfluous A records is disgusting. I'm shocked there haven't been more problems because of it. Recall Kashpureffs hijacking of the internic was done this way and one of the conditions of his probation was he had to explain to Kosters how to fix it. Ignore out of baliwick A records is still not well understood, and frankly made worse by the change to the structure of the DNS industry made by Commerce. It was bad enough when NSI had the wrong A record, but you could actually call them and get the to change it. Now each registrar can (and sometimes do) publish A records they shouldn't and the fun begins when two of them have different A records for the same name. It took a year to convince one of the top ten registrars staff that this was actually a problem.
So don't feel bad if you don't get it. Most of the industry doesn't either.
In theory you need one A record in the entire DNS. In can kick start itself from there. It's actually be shown to me you can rebuild the entirity of DNS just from scanning web pages.
But for practicial purposes you could get by with a very small number of A records in the legacy DNS. To be sure, things would be a bit slower, but "right" is better than "quick".
Need Mercedes parts ?
The Enigma extension for Thunderbird exists, is rather nice, and isn't setting the computer security market on fire.
Likewise, SMIME is built into modern email clients (and is dead-simple to use in Outlook Express) but is rarely used.
WE, the computer cognoscenti, the IT Crowd, have not brought our co-workers, family and other end-users over the psychological threshold that marks the transition from "password user" to "key user".
The main disincentive is that contemporary desktop operating systems do not make the key and the certificate into a tangible object such as a document, photo or mp3 file. There are no truly unified key-management "keychain" programs; keys and cert files do not get an intuitive icon and association with a keychain manager. So when regular users and power users start to grapple with signing and encryption, they become uneasy and frustrated in ways that the metal keys in their pockets or magnetic keys in their wallets do not.
Make it easy for people to actually handle keys and certs system-wide, and very many will begin using them.