Forgot your password?
typodupeerror
Security United States

Feds Tighten DNS Security On .Gov 140

Posted by CmdrTaco
from the totally-safe-we-promise dept.
alphadogg writes "When you file your taxes online, you want to be sure that the Web site you visit — www.irs.gov — is operated by the Internal Revenue Service and not a scam artist. By the end of next year, you can be confident that every U.S. government Web page is being served up by the appropriate agency. That's because the feds have launched the largest-ever rollout of a new authentication mechanism for the Internet's DNS. All federal agencies are deploying DNS Security Extensions (DNSSEC) on the .gov top-level domain, and some expect that once that rollout is complete, banks and other businesses might be encouraged to follow suit for their sites. DNSSEC prevents hackers from hijacking Web traffic and redirecting it to bogus sites. The Internet standard prevents spoofing attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption."
This discussion has been archived. No new comments can be posted.

Feds Tighten DNS Security On .Gov

Comments Filter:
  • by Punko (784684) on Monday September 22, 2008 @09:14AM (#25102805)
    "you can be confident that every U.S. government Web page is being served up by the appropriate agency."

    The easiest way entrap a victim is to promote a feeling of security.

    Nothing says 'rob me blind' than 'trust us'.
    • by PainMeds (1301879) on Monday September 22, 2008 @09:18AM (#25102865)
      Nothing says 'rob me blind' than 'trust us'.

      Which is why this originated from the IRS.
      • by Anonymous Coward on Monday September 22, 2008 @09:45AM (#25103217)

        who can squeeze every last drop of juice out of a lemon. So, the local strong guys line up and try....

        The first guy, a big burly construction guy give it a try and squeezes the lemon so that nothing comes out.

        A big body builder guy walks up and squeezes some more drops out but then nothing.

        Another big guy shows up and nothing. Just as the bartender was about to announce a winner, a small, bespectacled fellow wearing a business suit walks up and says in a mousy voice, "Let me try."

        Laughter ensues around the bar and they hand him the lemon. He squeezes and out pours more juice and he's declared the winner. The body builder asks, "How did you do that ?!?"

        The little guy answers, "I work for the IRS."

      • by noidentity (188756) on Monday September 22, 2008 @10:00AM (#25103393)

        On a similar note,

        When you file your taxes online, you want to be sure that the Web site you visit -- www.irs.gov -- is operated by the Internal Revenue Service and not a scam artist

        Wait, those are two different things?

      • I have full confidence in the IRS's ability to protect me from other groups seeking to take my money. Especially ones that take it tax deductibaly.

    • by Pecisk (688001)

      Paranoia modded up as insightful - yeah, what I'm talking about, this is Slashdot. Seemingly lacking touch with "real life" (tm).

    • Nothing says 'rob me blind' than 'trust us'.

      Everyone trusts them that it is the law that you must file your tax return. Wouldn't that violate the 5th amendment? [wikipedia.org]

      ...nor shall be compelled in any criminal case to be a witness against himself...

      You can be criminally charged for not filing your taxes and for filing your taxes incorrectly.

      However, I must stress that you should pay your taxes because the IRS probably has more guns, lawyers and judges than you do!

    • by jonaskoelker (922170) <jonaskoelker@gnu. o r g> on Monday September 22, 2008 @02:03PM (#25107753) Homepage

      "you can be confident that every U.S. government Web page is being served up by the appropriate agency."

      The easiest way entrap a victim is to promote a feeling of security.

      I would venture a guess: any visitor to *.gov who doesn't know what a packet is (i.e. at least 95% of the public) will already feel secure. Also, since the difference between secure DNS and insecure DNS will be absolutely invisible to them (presumably), they won't feel any more or less secure now. Or they won't know what the difference between the green padlock and the yellow padlock is. At any mention of the secure DNS in the press, these 95% of visitors will have forgotten about it the next day [just as I might].

      Bottom line: no one who doesn't deal with computers either professionally or as a hobby will notice. Their feeling of security will be unaffected.

  • by Anonymous Coward
    Now I can be sure I'm giving the IRS my money and not some other scam artist. I mean, not some scam artist. (:
  • by mfh (56)

    Yes, but with this handy +4 magic marker, spammers can bypass the multi-trillion dollar infrastructure and pwn your inbox.

  • Come se come sa
    • by cmaurand (768570)
      You're tag line: Use your head, can't you, use your head, You're on earth, there's no cure for that needs editing. It should read: Use your head. Can't you, use your head? You're on earth. There's no cure for that.
      • It's a quote from Sam Beckett's Endgame, which contains no '?' in any reference that I have found. There is no room to credit Sam Beckett in the sig.
      • by GundamFan (848341)

        Not that I'm an expert but given that it is a quotation the sentence, while technically not correct, could very well accurately represent what Mr. Beckett said or wrote. Please post a link to the quote on a reputable site so we can figure out which version is correct.

    • by Sique (173459)

      Comme ci, comme ca. (the c with an Cedille, but Slashdot doesn't know how to print that.)

      • Re: (Score:3, Informative)

        by psmears (629712)
        Yes it can—comme ça!

        (you need to use HTML character entities: "comme &ccedil;a". Slashdot only supports some—a fairly arbitrary subset—of these.)

  • It sounds like a good idea... Why do I feel that this is a user problem though that won't be fixed by a techy fix?

    When I read the headline, I thought that they were going to make sure everyone that uses the .gov domain was an actual government agency and not scam artists... That's some thing I'd hope that they are doing now, but I wouldn't hold my breath on it.

    The thing is this won't stop a stupid person from following irs-im-a-stupid-user-.com, .tv, .org, or .net.

  • How About They.. (Score:5, Informative)

    by neoform (551705) <djneoform@gmail.com> on Monday September 22, 2008 @09:24AM (#25102935) Homepage

    They really need to crack down more on sites like this one: http://www.usagc.org/ [usagc.org] while they're at it.

    WIN A FREE GREEN CARD! SIGN UP NOW FREE!*

    * $100 entry fee.

  • by Matt Perry (793115) <perry.matt54@yahoo.DALIcom minus painter> on Monday September 22, 2008 @09:28AM (#25103011)

    If my memory is correct, DNSSEC is one of the prerequisites for making opportunistic encryption easier to deploy widely. I hope this catches on and becomes more widespread.

    • by Lennie (16154)

      Totally agree that things like opportunistic encryption would be great, although I'm sure we'll get to see a lot of bugs and issues first before things get better.

    • In case anyone is wondering how this is possible, remember that you can store basically anything you want in DNS. For opportunistic encryption, you could store a cryptographic public key or an SSL certificate (or perhaps just its digest). Your application would query DNS for the data and, due to DNSSEC, be able to cryptographically verify that the proper owners of your nameserver (i.e., you) are the ones who put it there.

      Suppose you don't want to pony up the money for a properly signed SSL certificate from

  • Now if only... (Score:3, Insightful)

    by InvisblePinkUnicorn (1126837) on Monday September 22, 2008 @09:29AM (#25103023)
    Now, if only we could be confident about exactly where our taxes are going...
    • 100% of what is collected is absorbed solely by interest on the Federal Debt ... all individual income tax revenues are gone before one nickel is spent on the services taxpayers expect from government.

      -Grace Commission report submitted to President Ronald Reagan - January 15, 1984

      I'm sure I'll now be called crazy for simply reading a public document released by our own government.

  • by jamie (78724) Works for Slashdot <jamie@slashdot.org> on Monday September 22, 2008 @09:32AM (#25103049) Journal

    I've been told that DNSSEC is basically just a proof of concept when it's done on a single TLD, not providing much real security. If I understood it right, the main attack DNSSEC is intended to prevent is a man-in-the-middle returning a fake response to your computer's (or your ISP's computer's) DNS query, a fake that it accepts in place of the real response.

    If so, then when your ISP queries one of the thirteen root servers for the .gov authority, the attacker could still return a fake response and set himself up as the DNS authority for .gov, at least as far as your ISP knew.

    Anyone know how plausible that attack remains? Knowledgeable responses welcome :)

    Of course, part of getting DNSSEC set up for the whole internet is seeing how well it plays out in real-world testing, and .gov is the logical place to start. I assume once any kinks are discovered from this rollout, we'll be one step closer to enabling it on the root servers, which will allow any TLD to achieve a real security gain.

    • by jonaskoelker (922170) <jonaskoelker@gnu. o r g> on Monday September 22, 2008 @09:55AM (#25103339) Homepage

      I've been told that DNSSEC is basically just a proof of concept when it's done on a single TLD, not providing much real security. [...] If so, then when your ISP queries one of the thirteen root servers for the .gov authority, the attacker could still return a fake response and set himself up as the DNS authority for .gov.

      That would be my exact understanding as well.

      The details are these: Every node in the DNS tree has a key pair. Everybody knows the public key of the root. Every response to a request contains an answer, and a signature on that answer. As an additional request, you can ask for public keys too.

      So, here's the scenario for going to whitehouse.gov, assuming full deployment of DNSSEC:

      1. Ask root for whitehouse.gov
      2. Receive IP of nameserver for .gov [check its signature]. Root may opt to give you the public key of .gov, otherwise ask for it and its check signature.
      3. Ask .gov for whitehouse.gov
      4. Receive IP of whitehouse.gov [check sig]. Also, .gov may opt to give you the public key of whitehouse.gov
      5. Connect, now you know where to go :)

      This secures step 4. Step 2 is still not secured. Paul Vixie has given some good talks on DNSSEC and everything else that's wrong with the interwebs ;) See http://www.usenix.org/events/lisa05/tech/mp3/vixie.mp3 [usenix.org]. You may also like http://media.defcon.org/dc-13/audio/2005_Defcon_V7-Paul_Vixie-The_Internets_March_of_Folly.mp3 [defcon.org].

      • by squidguy (846256)

        1. Ask root for whitehouse.gov 2. Receive IP of nameserver for .gov [check its signature]. Root may opt to give you the public key of .gov, otherwise ask for it and its check signature. 3. Ask .gov for whitehouse.gov 4. Receive IP of whitehouse.gov [check sig]. Also, .gov may opt to give you the public key of whitehouse.gov 5. Connect, now you know where to go :)

        Ah, but it's more fun if you wind up at whitehouse.com

      • by Lennie (16154)

        You are mostly correct, actually it's even worse.

        This creates a false sense of security, because DNSSEC only works for those that support it and only works automatically for those TLD's that have it setup.

        There is something called DNSSEC Look-aside Validation (DLV) which DNS-admins can use to validate manually setup validation of a tld or in this case .gov, but I doubt anyone will do it.

        The only good thing is the software and procedures get tested better if .gov also starts using it.

        And maybe ever DNS-admin

        • This creates a false sense of security

          For at least 95% of the population, it doesn't do squat to the perception of security, and here's why I think this is so: http://it.slashdot.org/comments.pl?sid=971611&cid=25107753 [slashdot.org].

          And maybe ever DNS-admin 'inside' .gov will setup the DLV manually, that way all communication between .gov's might be better protected.

          My understanding is that DLV doesn't try to solve a security problem, but a deployment problem. DNSSEC requires keys on the path you want to travel in the DNS tree; DLV enables you verify the A-record path root-gov-whitehouse by following a key path starting at dlv.vix.com (or another dlv "pseudoroot" of your choice). Thus,

      • by Dolda2000 (759023)

        The details are these: Every node in the DNS tree has a key pair. Everybody knows the public key of the root.

        That runs against my understanding, though. I can't call myself an expert on DNSSEC, but as I've understood it, a client can have a trust anchor at any node in the tree. Thus, the client can have the public key of the .gov TLD pre-installed and check its replies against it.

        In fact, I think it seems haphazard to do otherwise. If the clients only knew and trusted the public key of the root server, then it would both require everyone to trust the root server operators (not that I don't, but I wouldn't want t

        • That runs against my understanding, though.

          You are correct: everyone can choose to trust any (sub)set of keys in the tree. What I explained is the intended deployment scenario Vixie put forth at, I think, lisa05. And he calls the root key "the uberkey, which really has to last the lifetime of the internet".

          If anyone h4xx3d the root zone's public key, they could fake the entire DNS.

          Which would be no worse than what we have now, except that we may have grown to rely on secure DNS. Even so, 95% of people wouldn't know what it means that the uberkey of the webpipes haz a hack-sored: http://it.slashdot.org/comments.pl?sid=971 [slashdot.org]

      • by spinkham (56603)

        For DNSSEC to work, you need either:
        1)Signed root
        2)signed TLDs with out of band pre-verification
        3)DLV.

        1) is the future.
        2) and 3) are what we are stuck with today, so I'll explain them.

        DNSSEC can be rooted anywhere you like, but the lower down the tree you go from the root the more keys you have to manually verify. For .gov to be secure, for example, every recursive DNS server operator would have to manually verify and install the .gov key. And they'd have to update it periodically, probably about yearly.

    • Re: (Score:3, Informative)

      by Dolda2000 (759023)
      I shan't call myself too knowledgeable about DNSSEC, but as far as I've understood it, it should be perfectly secure as long as the client systems have the .gov TLD's public key installed as an anchor of trust. Which they currently don't, of course, but that's another issue.
      • by dwheeler (321049) on Monday September 22, 2008 @10:27AM (#25103841) Homepage Journal
        You're quite right, it's perfectly secure if the client systems have the .gov TLD public key. And almost no one does, today. Of course, no one will bother trying to get DNSSEC or these keys until there's something to verify.

        This is a classic chicken-and-egg problem. The good news is that the U.S. government _CAN_ require that its OWN sites implement DNSSEC - and once that's done, people who deal with those sites (most U.S. citizens) will have a reason to install DNSSEC and the relevant .gov keys.

        What will probably happen is that there will be a Firefox plug-in (if there isn't already) that supplies these keys, and slowly browsers will add support for all this. The result: Accessing these sites will become more secure, over time. Good thing.
    • by mpeg4codec (581587) on Monday September 22, 2008 @12:35PM (#25106095) Homepage

      If so, then when your ISP queries one of the thirteen root servers for the .gov authority, the attacker could still return a fake response and set himself up as the DNS authority for .gov, at least as far as your ISP knew.

      Anyone know how plausible that attack remains? Knowledgeable responses welcome :)

      First, to answer your question regarding the plausibility: there are a few scenarios in which it is possible. The most likely scenario is that you're on the same local network as an attacker so that he/she can intercept your DNS traffic and forge replies. This might be the case when you're using the wireless provided at a coffee shop, for instance. There exist automated tools to make this simple, and I would consider this the biggest vector of attack. The only other case I can think of is that an attacker has control of a router between you and the root servers. While this is technically possible, I would personally regard it as fairly infeasible for the average attacker. If you're in $THIRD_WORLD_COUNTRY and the mob controls internet access, you might have something to worry about.

      I'm involved with a project called SecSpider [ucla.edu] that monitors the deployment of DNSSEC. We use a distributed network of pollers around the world to collect RRsets from all known DNSSEC-enabled zones. One of the reasons we use pollers from different locations is to detect attacks such as either of the two listed above, more likely the latter. If any attack were to occur, we stand the best chance of detecting it. We have been monitoring since 2005 and have yet to see such an attack.

      An additional benefit of collecting all these RRsets is that we have what we call a "world-wide perspective" on DNSKEYs. Whenever we collect a set of DNSKEY RRsets from a zone, if the set is consistent across pollers, we add it to our DLV repository. A DLV (DNSSEC lookaside validation) resource record is very similar to a DS (delegation signer) record. It contains a cryptographic hash of the DNSKEYs served by a zone so that the zone's integrity can be checked. However, instead of being served by the zone's parent, it can be served by anyone.

      The typical way in which a resolver detects if a zone is secure is by tracing a secure delegation from the root. Instead of the typical manner of starting at the root and querying recursively for NS records, the resolver queries for both NS and DS records. Then when it queries one of the nameservers listed in the NS records, it asks for the DNSKEYs and verifies them using the DS record. In this way, it is possible to build a chain of trust that leads all the way back to the root nameservers.

      Unfortunately, without the root being signed, this process will not work. One alternative is to configure your resolver to query for DLV records to bootstrap the process. When your resolver queries a zone for DNSKEY RRs, it will also query the DLV repository for a DLV recording matching that zone. It will then attempt to cryptographically verify the DNSKEYs using that record. If it verifies, you know that someone you trust thinks your DNSKEYs are right, side-stepping the typical chain of trust (thus the name: "lookaside"). If you were to configure your resolver to use our repository, you would be able to verify if the DNSKEYs you receive are the same as the DNSKEYs being seen by all of our pollers around the world. Not perfect security, but definitely an improvement on the current situation.

      If you're interested in the details of our project, you can check out our web site or ask me for more details. We have information on how to use our repository in our FAQ [ucla.edu].

      You mention the notion of real-world testing of DNSSEC. It's worth noting that there are actually several TLDs that are currently signed (mostly ccTLDs), as well as a large number of second-level domains. gov is hardly the first, but it should definitely be the highest-profile rollout to date. We're currently waiting with bated breath to see the outcome.

    • by hardaker (32597)

      Just like HTTPS and PGP require keys to get you started with your "trust", so does DNSSEC. With HTTPS you have a set of root CAs that you trust to issue certificates to web sites. Browsers, in fact, distribute a fairly mind numbingly large number of CAs that they accept as authentic providers of SSL certs to be trusted. PGP requires that you boot-strap your own trust by finding keys of all your friends before they send you important data you need to authenticate.

      DNSSEC is really no different. The onl

  • by mcgrew (92797) *

    some expect that once that rollout is complete, banks and other businesses might be encouraged to follow suit for their sites

    Might be encouraged? They should be forced to by law!

    • Re: (Score:3, Insightful)

      by Chyeld (713439)

      Why? Don't we have enough laws that attempt to legislate technology? Yes it's a desirable technology, but do we really need to be chained to it with a law that two decades from now will solely be an obstacle to implementing the next new desirable technology?

      Banks and other businesses will move to it once they see a good business case in doing so. Let that decide matters.

      Please understand, I'm not a laissez faire sort of fellow most of the time. But if you have the government start trying to decide how the c

      • by mcgrew (92797) *

        Don't we have enough laws that attempt to legislate technology?

        This isn't aout legislating technology, it's about protecting Grandma fro the bankers who don't give a rat's patoot whether or not Grandma gets stolen from.

        Banks and other businesses will move to it once they see a good business case in doing so

        Yes, THEIR interest. I don't care about their interest, I want protection against them. THEIR interest is what has caused the current banking crisis; deregulation has a large part of the current problem.

        I

        • by Chyeld (713439)

          Banks and other businesses will move to it once they see a good business case in doing so

          Yes, THEIR interest. I don't care about their interest, I want protection against them. THEIR interest is what has caused the current banking crisis; deregulation has a large part of the current problem.

          Their incentive is the fact that they are already on the hook for Grandma's money if she's scammed.

          And as an aside, you do realize that our current crisis

          1. Involved a completely different sort of bank that Grandma keeps
          • by mcgrew (92797) *

            Their incentive is the fact that they are already on the hook for Grandma's money if she's scammed.

            No, I'm afraid you're wrong. I had my car, a book of checks, and my bank card stolen. The woman who stole these things had watched me punch in the PIN number over my shoulder; she was NOT authorized to dip into my account.

            The police recovered the car, the bank made good on the forged checks, but not the debit card; if someone has your PIN number, no matter how they get it, they are authorized.

            I no longer use a

            • by Chyeld (713439)

              No, I'm afraid you're wrong. I had my car, a book of checks, and my bank card stolen. The woman who stole these things had watched me punch in the PIN number over my shoulder; she was NOT authorized to dip into my account.

              The police recovered the car, the bank made good on the forged checks, but not the debit card; if someone has your PIN number, no matter how they get it, they are authorized.

              I no longer use a debit card because of that.

              And this has to do with the current discussion of "grandma" being scamm

              • Re: (Score:3, Insightful)

                by AnyoneEB (574727)
                He is giving an example an attacker getting access to his debit card and the bank taking no liability for it. You are free to complain about him whining because you think he should be the one liable not the bank (that is a different, irrelevant argument), but the topic of discussion is that the bank customer is liable not the bank. This means the bank has no incentive to improve their security. In fact, better security probably costs more -- at least the cost of paying someone to figure out how to fix probl
                • by mcgrew (92797) *
                  You hit the nail on the head. Not a whine, an example. I solved the problem of never knowing when someone is looking over my shoulder by not having a debit card, problem solved.
                • by Chyeld (713439)

                  The point of my comment was not to 'complain about him whining because you think he should be the one liable not the bank', and in fact I didn't.

                  The point of my comment was to point out that simply because that particular hole exists for debit cards it doesn't have anything to do with the issues he's trying to argue we should have laws 'protecting us' from the banks for.

                  There are laws in place aready to protect us from those issues. Read up on identity theft law and you will see that the banks are on the ho

                  • by AnyoneEB (574727)

                    Okay, so debit cards are insufficiently protected by the law, but identity theft via website hacking and/or phishing is protected. That sounds like a sane reason to invalidate mcgrew's example.

                    On the other hand, the assertion that banks care about security strikes me as ridiculous. Why are we still using authentication systems where logging in involves transferring all of the knowledge needed to log in as opposed to some sort of challenge response? Randomly asking security questions helps this a little, but

  • SSL, anyone? (Score:3, Insightful)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday September 22, 2008 @09:36AM (#25103105) Journal

    What does DNSSEC buy me if I use https?

    And if irs.gov isn't supporting https, wouldn't that be the place to start, rather than DNSSEC?

    • by Chrisq (894406)
      Absolutely. Without https you could be subject to a man in the middle attack. This is at least as big a hole as a DNS spoofing/cache poisoning.

      They would have been a lot better of going https with extended validation certificates and widely publishing the fact that with a modern browser you should see a green address bar, that would have ensured that dns spoofing and man in the middle attacks would be detected.
    • The 2 things are orthogonal to each other. DNSSEC insures that the site you go to is ACTUALLY the site you wanted to go to.

      HTTPS just encrypts the traffic to/from that site once you get there.

      In principle an SSL cert insures that the site is what it claims to be, but there are so many possible ways to fool people on that score that it really isn't all that effective.

      Besides, if someone subverts DNS, then basically all bets are off anyway because at that point they have the ability to make any particular URL

      • by ultranova (717540)

        The 2 things are orthogonal to each other. DNSSEC insures that the site you go to is ACTUALLY the site you wanted to go to.

        HTTPS just encrypts the traffic to/from that site once you get there.

        Not true. HTTPS also includes a certificate-based indentifying system. Otherwise it would be pretty worthless, as nothing would stop a man in the middle from intercepting the initial contact attempt.

        • HTTPS also includes a certificate-based indentifying system.

          More precisely, SSL/TLS authenticates the server you are talking to based on it's domain name and the certificates common name provided one of the following is true:
          • The servers certificate is signed by a trusted CA. A trusted CA means the CA certificate is in the browsers (in the case of a web browser) certificate store.
          • OR The servers certificate is self-signed, and a copy of that self-signed certificate is in the browsers certificate store.
        • Actually unless BOTH the client and server must present certificates (which is not supported by any web site I know of) then a MITM attack is PERFECTLY feasible over SLL.

          It is true that if I'm 'evil hacker' and I spoof your DNS for say www.irs.gov then I have a problem that if that URL is HTTPS I don't have a copy of their SSL certificate and I can't get one that will work without a pop up warning.

          HOWEVER that is rarely the case, home pages are always straight HTTP. So evil hacker can now present me with an

          • by blueg3 (192743)

            This is the well-known "login page is not over https" problem.

          • by Burz (138833)

            You don't know what you're blathering (at length, I might add) about.

            Operating systems and browsers come with the public keys of the OS distributor and Certificate Authorities built-in. Unless the responses of the spoofer/MITM system can be validated with these crypto keys, then the user will be warned that the remote site is trying to use an invalid cert. But the spoofer doesn't have the private key of the OS Distro or CAs, so they can't generate responses that jibe with the client's crypto.

            If you take ove

            • http://www.monkey.org/~dugsong/dsniff/faq.html [monkey.org]

              Section 3.4, and I quote

              Although HTTPS and SSH are encrypted, they both rely on weakly bound public key certificates to identify servers and to establish security contexts for symmetric encryption. As the vast majority of users fail to comprehend the obtuse digital trust management PKI presents (e.g. is an X.509v3 DN really meaningful to you?), a simple monkey-in-the-middle attack works quite well in practice.

              Client traffic to a target server may be intercepted

              • by Burz (138833)

                Somehow I knew if you responded, you would start with the assumption that users will bypass the certificate warning.

                My users don't accept bogus certificates; they know to watch for the Lock + proper domain together in the address bar because I communicate basic browsing knowledge to them. So what is wrong with your users?

                • Hahahaha, yeah, right.

                  Several studies have been done on what users actually will and won't do. If your security is based on the myth that your users will do the right thing, then you HAVE no security.

              • by Burz (138833)

                Stop behaving like a hysterical hack!

                Relying on bugs and physical access (for crissesake) is not an attack on the protocol itself. Esp. when the implementation being discussed is a six year-old version.

                Every complex piece of software has bugs, particularly early-on. You seem to think that DNSSEC implementations will somehow be an exception.

                • DNSSEC has been around for quite some time. It isn't some kind of brand new protocol.

                  I also never said that DNSSEC was some kind of panacea. It is a NECESSARY component of a secure internet. Without it you can't be secure. I never said that HTTPS wasn't also a component of security, all I said was if you think HTTPS BY ITSELF is making you secure, then you are just plain demonstrably WRONG.

          • HOWEVER that is rarely the case, home pages are always straight HTTP.

            https://www.paypal.com/ [paypal.com]
            https://mail.google.com/ [google.com]

            It's worth mentioning that if the government is going to go to some expense to implement DNSSEC, it would be far more beneficial for them to simply SSL all their sites.

            there are trivially simple ways evil hacker can present content to me that will be HTTPS and yet be going to whatever site he does control, like simply pointing an insecure FORM at an HTTPS target on a URL evil hacker DOES own

            Except that if the page that form is on is encrypted, he can't intercept it and send the form. That is, unless said page is on a domain he controls, as you say -- in which case, the URL will be https://evilhackersite.com/whatever [evilhackersite.com], and I won't fill out the form, nor will my browser auto-fill my i

      • by smoker2 (750216)
        I don't agree there. If the US Govt can't get their own Authority key added to the browser (like Thawte, verisign etc) then they're not trying. It's pretty hard to circumvent a built in device by getting a cheapo freessl cert. They could even make it so that when you access such a govt. site, a big popup tells you that you ARE at a govt. site.
        It's cheaper to include a new Authority in the browser than change the whole DNS system worldwide.
        • Sure, but if I control your DNS I can just patch your browser to do whatever I want... So for example I can install my own root cert.

          DNS HAS to be secure, all other aspects of security on the net indirectly depend on the integrity of DNS, and once that is gone, then you have already lost all other battles. Its game over.

          • by blueg3 (192743)

            Except that automatic-update systems, such as what you would use to patch the browser against the user's will, only accept signed packages. You can hijack the domain name and send them all the malicious data you want, but they won't install it for you, because the browser doesn't implicitly trust the domain name.

            DNS does not *have* to be secure. It just makes it much more convenient.

            • by Burz (138833)

              Even the convenience is questionable. Just maybe DNSSEC would prevent webmasters from having to convert "http://etc" links to "https://etc" en-masse.

              Then again, if the sensitive parts of the site are already https, then why bother? Even from a resource-use perspective, the crypto burden may be only slightly less than https.

              • by blueg3 (192743)

                DNSSEC protects things that aren't secured by https, like MX records. I suspect it's also easier to implement than forcing everyone to move to HTTPS and other encrypted protocols.

                The parts of the Web where you don't care about security are built around HTTP, but there's still value in preventing them from being hijacked.

                • by Burz (138833)

                  DNSSEC protects things that aren't secured by https, like MX records.

                  And if email is sent via SSL connections?

                  What is so bad about making SSL/https the default? All digital signature schemes are based on crypto anyway; actually performing the crypto uses hardly any more resources than validating DNS because the burden is almost all in the public key overhead.

                  Who would administer the root cert? Oh, let me guess... the U.S. of A. government who just happens to be the first mover on implementing this more-centralized-than-https scheme.

                  But I suppose one can feel secure that DNSS

                  • by blueg3 (192743)

                    It's unwise to run a DNS server on the same machine as an HTTP/HTTPS server anyway, so DNSSEC will put no additional load on those servers. (They will put additional load on DNS servers, and that limits adoption.)

                    The US government doesn't administer any of this, and they're not by any means the first mover on this. They just happen to control quite a few websites and make press releases.

                    As far as sending e-mail via SSL, are you familiar with what MX records do? It should be clear that SSL provides absolute

                    • by Burz (138833)

                      The US government doesn't administer any of this, and they're not by any means the first mover on this. They just happen to control quite a few websites and make press releases.

                      So there are other TLDs already on DNSSEC?

                      Its still highly centralized and the official status of not being controlled by US govt is merely a pretense in a country that so frequently goes on a war footing. It is also the same govt that is now working with China in the IETF to irradicate anonymity from the Internet.

                      As far as sending e-mail via SSL, are you familiar with what MX records do? It should be clear that SSL provides absolutely no protection for MX record poisoning.

                      It can protect a mailer from sending mail through an impostor. I believe that MX records might still be sabotaged by an attacker, such that routing preferences could be forged and causing traffic

                    • by blueg3 (192743)

                      It's perfectly valid for the MX record to specify that the mail handler for foo.com is mail.foo.com, or even mail.bar.com. Valid and common. To send the mail, then, you're connecting to mail.bar.com. Say this SSL connection is authenticated such that you're sure you're talking to mail.bar.com.

                      So, the attacker just changes the MX record to mail.evil.com. (Through, for example, DNS cache poisoning.) So, now you set up an SSL connection to mail.evil.com, and you're sure you're talking to mail.evil.com.

                      The SSL

                    • by Burz (138833)

                      So, the attacker just changes the MX record to mail.evil.com.

                      Sure, real simple... Just need to find mail and DNS servers sitting on the same subnet as some cheesy, infested PCs. Then execute the attack which BTW leaves the attacker with a verified IP/identity and a big "arrest me!" sign on their back.

                      The chances of this happening are...?

                    • by blueg3 (192743)

                      You (a) shouldn't base a security approach on having no malicious computers on your subnet (b) don't need access to the subnet to execute this attack and (c) don't even need access to the routing path (which you could obtain without being on the same subnet with BGP hacks, among others).

                      All the information the MX record contains is the address of a machine you can control. It doesn't have to be yours, as long as you control it.

                      Using MX forging to redirect mail traffic in exactly this manner has been used in

                    • by Burz (138833)

                      LAN security is as important an aspect of physical security as any other.

                      The rest of what you're saying seems pretty specious, esp. the hand waving about BGP; That's like worrying about whether the Russian Navy warship is going to break into your safety deposit box at the Post Office. :-D

                      With all of the worry over warrant-less spying, webmasters and an increasing number of clients will probably just opt for a validation system they already know (https) and reap the data encryption benefit at the same time.

                    • by blueg3 (192743)

                      In case you didn't read, I did mention that a successful attack requires neither access to the internal network nor BGP hijacking.

                      Considering BGP hijacking has also been successfully done (recently) and is an excellent way to get access to communications, I'd hardly call it specious. Yet secure protocols like DNSSEC and HTTPS provide security in the case where your route goes through hostile nodes.

                      Again, by hijacking the MX record for a domain -- an attack that doesn't require any particularly privileged ac

  • Scam (Score:3, Informative)

    by Arthur B. (806360) on Monday September 22, 2008 @09:37AM (#25103111)

    www.irs.gov â" is operated by the Internal Revenue Service and not a scam artist

    www.irs.gov is operated by a scam artist

    There, fix that for you.

  • by Chrisq (894406) on Monday September 22, 2008 @09:44AM (#25103201)
    Before I took up their cash-in hand job offer to deliver a package to their embassy in Islamabad. I've started to wonder whether the ticking really is an alarm clock. ;-)
  • by otacon (445694)

    So when I went to the IRS site to pay my taxes and it said I was the 1 millionth visitor and won an iPhone, that wasn't real? Now I kno why I've been waiting months for this thing to come in the mail.

  • by dwheeler (321049) on Monday September 22, 2008 @09:54AM (#25103317) Homepage Journal
    This won't solve all the problems of the universe, but this is a GOOD THING. Securing DNS is absolutely critical to making the Internet a safer place. If I type in "irs.gov", I want to go to "irs.gov", not some spam site, and this helps me get there. DNSSEC can provide IP addresses with a strong guarantee that the IP addresses are actually correct. DNSSEC can even provide other keys, and make it possible to EASILY send secure emails without having to do a key exchange ahead-of-time. See, for example: http://www.dwheeler.com/essays/easy-email-sec.html [dwheeler.com]
    • by gkuz (706134)

      If I type in "irs.gov", I want to go to "irs.gov"

      It's 2008. Does anybody type URL's any more?

  • File by paper, particularly if you have to pay out. You get it in the mail and your money stays in your account earning you a little more interest for a few more days.
  • Not so fast! (Score:3, Interesting)

    by duplo1 (719988) on Monday September 22, 2008 @10:19AM (#25103691)
    My understanding is that unless DNSSEC is implemented in the last mile resolvers (e.g. my ISP), it doesn't buy a whole lot, especially when it comes to preventing cache poisoning attacks. Moreover, according to RFC4035, delegation records and glue records aren't subject to public key verification (i.e. not signed), so DNSSEC could still be vulnerable. Until DNSSEC is pushed out to the end user to the point that are browsers are performing signature verification, I don't think it's going to buy us the security we're looking for. Even then, with PKI being notoriously difficult to implement, I'm sure it will be botched and somebody will find ways to poison public key registries with fake public keys, etc.
    • by amorsen (7485)

      My understanding is that unless DNSSEC is implemented in the last mile resolvers (e.g. my ISP), it doesn't buy a whole lot, especially when it comes to preventing cache poisoning attacks.

      DNSSEC was written with the explicit goal of not having to trust or upgrade servers in the middle. Your machine needs to to the DNSSEC verification itself. Not the browser, or you would only have secured the browser. Not the last mile resolver, as you call it, because you can't trust that.

    • by hardaker (32597)

      You have to decide if you want to trust your ISP to do validation for you or if you want to do validation yourself (the average Joe will likely have this decided for them). If you trust your DSL (whatever) link to your nearest validating resolver (you're ISPs) and you trust your ISP, then you have functionally a secure(ish) path. If you're more paranoid, then get a on-system validating resolver or validating applications (the DNSSEC-Tools project has a validating version of firefox2).

      And the DS record (

  • Since accountability evasion has proven notoriously hard [google.ca] to fix, and shows every sign of being an ongoing problem. [google.ca]
  • by OpenYourEyes (563714) on Monday September 22, 2008 @11:19AM (#25104745)
    Ignoring if DNSSEC is good or not, this is a pretty bad example of why to do this. Nobody goes to irs.gov to file their taxes. Instead, they go to a third-party (like Quicken, as just one example) who will file their taxes with the IRS. This was part of a deal worked out many years ago - in exchange for the IRS not providing its own e-file solutions, the third-party companies would have to provide free online e-filing (but would still, of course, be able to sell their own software to do the same thing).
  • Since when does www.irs.gov allow you to file taxes? Last I checked, they only list other sites that allow you to file... None of which are .gov.
  • Maybe someone will finally fix the apparent glaring security hole [nhliberty.org] in New Hampshire's .gov website [state.nh.us].
  • It is a good thing I think that the government is adding this extra step of security. While I will never believe anything is crack-proof, the more layers the better, and anything is better than nothing. However, for several years it seems the U.S. Post Office has been going in the wrong direction, because (and I just checked this again) when you navigate to http://www.usps.gov [usps.gov] you are automatically redirected to http://www.usps.com [usps.com]. Apparently they want people to think they're a commercial business instead

Debug is human, de-fix divine.

Working...