Slashdot Mirror

← Back to Stories (view on slashdot.org)

Experts Tell Feds To Sign the DNS Root ASAP

Posted by kdawson on from the digital-john-hancock dept.

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.

16 of 147 comments (clear)

  1. Trolls equal... by Jizzbug · · Score: 1, Interesting

    ...something with an uncommon opinion. In my experience, the trolls are usually right.

    --

    -=/\- Jizzbug -/\=-
  2. DNSSEC ready for prime time? by jonaskoelker · · Score: 3, Interesting

    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.

    1. Re:DNSSEC ready for prime time? by supradave · · Score: 1, Interesting

      Yes, it's ready. Secure64 has a secure operating system that was written from scratch to take advantage of the features of Itanium2 and a TPM, that is immune to rootkits and malware, that can hide the keys and sign the zone. One line in the NSD-like config, 'dnssec-automate: yes' and your zones are signed with 'best practice' key lengths and roll-over times.

      But it's not open source. How could anyone trust it? Independent labs have verified the claims. Yes, we're trying to sell a product that solves a problem and we're the only company that has the secure platform to do it with.

      It can act as the authoritative signer or it can plug in between your current authoritative and slaves and do a man-in-the-middle signing. No real changes to the infrastructure required.

      Nothing stopping people from abusing themselves with doing it manually.

      And it's DDoS resistant and does over 100,000 DNS qps, even under a DDoS attack (up to wire saturation).

    2. Re:DNSSEC ready for prime time? by arotenbe · · Score: 3, Interesting

      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.

      In fact, that was what got us into this mess in the first place. We can't replace any part of the internet without breaking everything, so we just keep tacking on new standards and quick-fix patches. Someone needs to redesign the whole thing with an generalized, expandable security model. But then we would have two internets...

      "I think the problem here may be more of a question of getting rid of the bad internets and keeping the good internets."

      --
      Tomato wedge sperm darts that are Republican.
    3. Re:DNSSEC ready for prime time? by afidel · · Score: 3, Interesting

      That RFC makes my head hurt. After a few readings I can usually grok most RFC's, but that one is particularly dense with acronyms and references to other DNSSEC concepts not included in the RFC. Also I don't see any provision for multiple signers, my ideal system has each of the ROOT servers having their own key and each zone being signed with each of the keys from the ROOTS they trust. That way if some government or corporation does something you disagree with you can choose to revoke their key as either a signor or a receiver.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    4. Re:DNSSEC ready for prime time? by rs79 · · Score: 2, Interesting

      "Is DNSSEC ready for prime time?"

      Nope.

      I note with relish Vint Cerf and Joe Baptista, who couldm't be more apart on DNS agree that something othre than DNSSEC shuld be used. This is probably the only thing they agree on. And they're quite right.

      --
      Need Mercedes parts ?
  3. Why bother? For a CHEAP PKI... by nweaver · · Score: 5, Interesting

    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
  4. not so fast by ejtttje · · Score: 5, Interesting

    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.

    1. Re:not so fast by Intron · · Score: 2, Interesting

      Unfortunately, the comment is wrong. The Kaminsky bug is not cache poisoning by fraudulent UDP packets (which is a concern), it is using glue records to provide false NS address. Example:

      You visit a website which pulls an image from subdomain.malicious.example.com. To get that, you need to know its nameserver. So you ask malicious.example.com who tells you that the nameserver is ns.citibank.com and oh, BTW that address is 666.666.666 (glue record). Now your cache has a phony address for ns.citibank.com. This would be the same whether you were using TCP, UDP or carrier pigeon. Glue records are part of the DNS protocol.

      The way to fix the Kaminsky bug is not to switch to TCP or DNSSEC, it is to not cache glue records.

      --
      Intron: the portion of DNA which expresses nothing useful.
    2. Re:not so fast by Wowlapalooza · · Score: 3, Interesting

      That was the Kashpureff attack, not the Kaminsky attack. Your understanding of DNS cache poisoning attacks is unfortunately about a decade out of date. All major resolver implementation now do "bailiwick checking" and aren't fooled by crude, cheap tricks as you describe.

      The Kaminsky attack does use forged packets, which then poison the cache with bogus NS records in ways that are not blocked by bailiwick-checking. These bogus NS records then "redirect" future queries of names under the same delegation point. Yes, using TCP exclusively would add much more entropy to DNS transactions, and thus make them much more resilient to forgery and thus to Kaminsky attacks.

      But, at what cost? TCP is a hog, and typical DNS servers perform many millions of queries a day. Tens of millions and even hundreds of millions, are not uncommon.

      Also, the DNS standards explicitly say that TCP is used for ordinary queries only as a fallback in case the response doesn't fit in a UDP packet -- and since the introduction of EDNS0 it's actually becoming quite rare for TCP fallback to become necessary. So the standards would have to be updated, and DNS software would then have to be modified to reflect the new standards. DNSSEC has a huge head-start on your "TCP exclusively" proposal along the standards-approval process.

      Lastly, many firewall rulesets wouldn't allow TCP queries and responses as a regular occurrence, so they would need to be updated as well

      All of this would take many years to implement. From a cost/benefit standpoint and a how-soon-to-implement standpoint, DNSSEC comes out ahead of "TCP exclusively" and what you get when all is said and done is superior protection against Kaminsky attacks.

      "TCP exclusively" isn't a particularly original idea, by the way, see http://www.merit.edu/mail.archives/nanog/msg10298.html (August 9) and the subsequent discussion

  5. Centralized DNS really the answer? by NinthAgendaDotCom · · Score: 3, Interesting

    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/
  6. An explanation please? by PhysicsPhil · · Score: 4, Interesting

    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?

  7. Why only one CA? (And it's the feds?!) by Sloppy · · Score: 5, Interesting

    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.
  8. Re:exactly by Sloppy · · Score: 2, Interesting

    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.
  9. why only one CA by bugs2squash · · Score: 4, Interesting

    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
  10. Re:Why would the establishment prefer DNSSEC by Burz · · Score: 3, Interesting

    Because SSL and DNSSEC solve two different problems. Unless you're doing DNS-over-SSL, which means running DNS in TCP mode.

    I don't think so. A primary motivation for PKI-backed SSL was to protect against any misdirection, whether at the domain-name or IP address level.

    DNS over TCP isn't being suggested here. Normal DNS with a PKI-using protocol like HTTPS is what provides the protection I'm talking about. Its the scheme you and I already use whenever we make a purchase or do online banking.

    In the case of HTTPS, a interfering with either DNS resolution or misrouting an IP address will cause the connection to stop with a warning. In the case of DNSSEC, interference will generate an error message that most server and client software does not understand.

    With SSL/HTTPS/etc. the address is verified outside the DNS protocol. But it is still verified. Moving that verification into DNS doesn't really help unless you prefer to see most internet traffic remain unencrypted.