Archive for category Uncategorized

Five leading Internet security have written a whitepaper detailing their concern that an intellectual property bill under consideration in the U.S. Senate would undermine the efficacy of DNSSEC through its mandates for domain name system filtering.

Steve Crocker of Shinkuro; David Dagon of Georgia Tech; Dan Kaminsky of DKH; Danny McPherson of Verisign; and Paul Vixie of the Internet Systems Consortium co-authored the whitepaper to detail their concerns about the Senate bill 978, the Preventing Real Online Threats to Economic Creativity and Theft of Intellectual Property Act of 2011 (“PROTECT IP Act”).  The authors note that the legislation’s requirements are in conflict with current DNSSEC deployment efforts:

The U.S. Government and private industry have identified DNSSEC as a key part of a wider cyber security strategy, and many private, military, and governmental networks have invested in DNSSEC technologies. If implemented, this section of the PROTECT IP Act would weaken this important effort to improve Internet security. It would enshrine and institutionalize the very network manipulation that DNSSEC must fight in order to prevent cyberattacks and other malevolent behavior on the global Internet, thereby exposing networks and users to increased security and privacy risks

By deploying DNSSEC in the .com top-level domain last Thursday, VeriSign–the TLD’s operator–gave more than 80 million registered domains access to improved domain name security.  “DNSSEC finally goes mainstream,” read one headline in coverage of the move.

The .com top-level domain joins more than 25 other TLDs–including .gov, .edu, .org and .net –since the root was signed last July, providing DNSSEC protection at the top of the hierarchy.

Noting that most respondents think DNSSEC adoption is inevitable, a survey was released just before the .com signing by Internet Identity and the Online Trust Alliance, suggesting more education needs to be done.  The survey “found that half of the respondents either hadn’t heard of DNSSEC or expressed limited familiarity with it. Those who do understand the technology believe key obstacles including lack of training/implementation services, slow ISP resolver rollout and limited client-aware applications will lead to a two to five year adoption period.”

ICANN CEO Rod Beckstrom opened the organization’s 40th meeting in Silicon Valley citing DNSSEC as a major theme in his keynote presentation (119KB PDF). Following are his DNSSEC-related remarks:

Perhaps our most significant security achievement is the ongoing implementation of DNSSEC. With strong community support, it is being vigorously deployed around the world, at a pace that exceeds our most optimistic projections.

We encourage companies to deploy DNSSEC on their DNS infrastructure – in effect, to turn DNSSEC validation “on” and sign their company’s domain names.

In less than a year since the root was signed, today we have 76 top-level domains signed and in a few weeks, .COM – with almost 100 million domains names – will also be signed.

With the root zone signed, the number of domains using DNSSEC will accelerate. Large ISPs such as Comcast are deploying DNSSEC to provide additional security for their customers, and major equipment vendors such as Cisco are looking at building it into their products. This is a major win.

And finally, DNSSEC could help secure more than just domain names – perhaps email, web sites, identities, communications and programs – bringing seamless and trustworthy communication across organizational and national borders.

For those of you who may not be fully familiar with DNSSEC, there will be a session for newcomers today at four o’clock.

The Latin American and Caribbean TLD Association has set a target of 50 percent signed TLDs in Latin America by the end of this year. “2011 will be the year of DNSSEC for LAC TLD,” according to its general manager.

We want to hear that commitment echoed around the world.

ICANN’s Silicon Valley meeting has begun, and features two substantial DNSSEC presentations. Audiocast information, presentations and details can be found at the session links below:

DNSSEC for Everybody: A Beginner’s Guide takes place today at 4pm Pacific Time. Presenters from ISC, Nominet and Verisign will walk participants through basic and core concepts of DNSSEC, as well as real-word examples and a sample implementation of DNSSEC, with which audience members can interact.

The DNSSEC Workshop takes place Wednesday, March 16, starting at 8:30am Pacific Time.  DNSSEC deployment plans will be discussed by speakers from Akamai, Cisco, Fedora, Mozilla, PayPal, and Xelerance.  Application Security with DNSSEC and DOSETA will be presented by Brandenburg InternetWorking, and speakers from .nz Registry services and Google will address Innovative Uses as a Result of DNSSEC. Activities from the North American region will be presented by speakers from CIRA/.ca and VeriSign. The session concludes with a discussion of DNSSEC signing services with speakers from Afilias, EURID, ISC, Nominet, Packet Clearing House and Verisign.

DNSSEC has been successfully announced in the .co top-level domain, it was announced yesterday.  

AFNIC, which manages the .fr country-code top-level domain, has issued a DNSSEC deployment incident report detailing what happened on February 12 when “the .fr zone becomes inaccessible to any validating resolver outside business hours. The problem concerns a certain type of record (NSEC3) which is not yet monitored, and for this reason our warning system does not report the incident.”

The report includes a step-by-step account of the incident and responses to it, and concludes, “DNSsec is still a complex form of technology, and not all the software layers used in it have yet been tested in production in all of the configurations. It is therefore understandable that a certain number of bugs may still be encountered. The reactivity of the ISC in particular and the sharing of experience feedback by and between registries nevertheless make us feel confident that this stabilisation period will be as short as possible and will not affect the possibilities of large-scale go-live of DNSsec.”

ICANN has issued a new report on DNSSEC-signed top-level domains. It notes that:

The report includes a detailed listing of TLDs and their status regarding DNSSEC deployment.

(Editor’s note:  Andrew Sullivan, author of this post, works for Shinkuro, is a member of the DNSSEC  Deployment Initiative, and is co-chair of the DNS Extensions working group at the IETF.  In the past, he was part of the DNS group at Afilias, and worked on Afilias  projects starting with the launch of the .info top level domain in 2001.)

Now that the largest TLDs on the Internet are either already DNSSEC-capable or about to be signed, what do we do with DNSSEC?

This might seem like a strange question.  If we didn’t know in advance how DNSSEC would improve things, why did we other?  The answer is in two parts.

In one way, DNSSEC deployment automatically improves things.  We had an integral part of the Internet (the DNS) that was designed back when cryptography was both expensive and controlled, and when the Internet population was small.  It had no security.  So we had to plug that hole: alter the DNS so that if you got an answer from it, you could be absolutely sure whether you got the answer you should have, and not something from some random person on the Internet.  That’s stage 1. It isn’t over yet, and won’t be until every DNS answer on the Internet can be validated.  But we’re on the way, and for many domains it is now just a matter of time before this is reality.

Stage 2 of DNSSEC deployment is the really exciting part.  The DNS contains mappings of host names to addresses, of course, and securing those lookups is one thing that DNSSEC gives us.  But we can put other kinds of data into the DNS as well, and turn the DNSSEC-enabled DNS into a successful public key infrastructure.  This solves a problem that has dogged the online world for years.

Consider the web.  The way secure connections are made on the web today relies on a third party — the certificate authority or CA. Suppose you are visiting the web site https://secure.example.com.  The secure web site presents your browser with a certificate.  In the usual case, your browser now looks into a big list of CAs it trusts. If one of those CAs provided (either directly or indirectly through another certificate) assurances about the certificate from secure.example.com, then you trust the site you are visiting. Otherwise, you get a warning (sometimes a big, scary one) saying that the site cannot be validated.  This is an oversimplification of how https validation works, but that’s roughly all there is to it.

The reliance on CAs means two things.  First, it means the operator of secure.example.com has to have registered with one of the certificate authorities (and not just any one — one of the ones you have in your list).  This involves money and not a little time managing the keys appropriate to each host or collection of hosts.  If the operator of the service does not register with one of the certificate authorities, then when you connect you will get a certificate that cannot be validated.  Maybe you won’t be able to connect, and you will be foiled in what you are trying to do.  Or maybe you will accept the unknown connection, which means that you could be giving your credit card to anyone at all on the Internet.

Second, it means that you have to trust all these third parties, and keep the list of those parties in your browser up to date.  That might not sound like a problem, except for two things.  First, we know people don’t always install updates right away.  Second, some of the CAs have made some pretty big blunders in the past.  Since you probably have other things to do, it is unlikely that you will go through the list of CAs and make decisions one at a time about whether that CA is responsible. 

DNSSEC makes it possible to replace this machinery.  With DNSSEC, you can trust that the DNS data you get about secure.example.com is the real thing: nobody can spoof it.  This means that if the administrator of  secure.example.com could put the necessary key information into the DNS, you could just look it up there, and be sure that the data you got back was right.  Then you could use that data to secure your web connection.  In this ca se, you don’t have to trust any third parties, and the site operator doesn’t have to involve any third parties (or pay any money to them) either.  The work needed to make this happen is already being done at the Internet Engineering Task Force (IETF) in the DNS-based Authentication of Named Entities (DANE) working group. Participation is open.  For more details, see http://tools.ietf.org/wg/dane. But the technique needn’t be just for the web.  On the web, most secure sites are using certificates signed by a CA today, and so one could argue that there is no reason to fool with  something that is working.  But other services aren’t like that.  The overwhelming majority of SMTP servers that use TLS are using self-signed certificates.  This means the authentication mechanisms already available to us are not even being used.  This contributes to the spam problem — but it is too much hassle to use CA-signed certificates for mail systems, so nobody does it.

Authentication for VPNs is also an area ripe for developments using DNSSEC.  Today, configuration of VPNs is often a headache for IT staff, who often either have to touch every computer that will participate in a VPN in order to set it up, or else distribute software via some unsecured channel and use “leap of faith” as the first step in the validation chain.  DNSSEC could be used to perform that initial bootstrap of trust, freeing up IT staff time and making VPN connections much easier.  SSH has already shown part of the way to do this, using the SSHFP resource record.  Once you have a provably trustworthy, globally-available database, it becomes obvious that many problems of establishing initial trust go away.

DNSSEC is not magic, of course.  Nothing will help you get to the right server if the operation at secure.example.com has been taken over by a bad guy.  Putting keys or certificates into the DNS will not make website operators’ lives better if the person who runs the DNS won’t co-operate.  But those are not new problems, and they are problems that are best solved with management direction.  And none of this leveraging of DNSSEC is ready today: the tools don’t exist, the protocols are only just being designed, and DNSSEC itself is still hard enough to use that people make mistakes all the time.  But DNSSEC gives us an incredibly exciting opportunity to make practical, easy to use security gains available to everyone on the Internet.  It’s time to concentrate on stage 2.

VeriSign has been selected by the U.S. General Services Administration to operate the .gov domain name registry, following a competitve proposal and review process.  Full support of DNSSEC for .gov and fed.us will be part of VeriSign’s responsibilities under the contract.

The announcement comes as a new study shows that fewer than half of all U.S. government agencies have not yet deployed DNSSEC, despite a government-wide mandate that they do so by the end of 2009. In its article Half of federal web sites fail DNS security test, NetworkWorld notes:

Secure64 Software Corp., a DNS vendor, tested 360 federal agencies for evidence of digital signatures on their .gov domains. The company ran the same test a year ago and found that only 20% of federal Web sites were in compliance with the DNSSEC mandate.

“We checked which ones of those Web sites were signed, which is the first step to deploying DNSSEC,” says Mark Beckett, vice president of marketing and product management for Secure64. “Last year, that number was 20%. This year, that number is 49%.”

The study notes that some U.S. federal agencies have fully deployed DNSSEC or are close to doing so, including the Department of State, which is 100 percent compliant, and the Department of Labor, which is 90 percent compliant.

The Winter 2011 meeting of the Internet2 JointTechs was held Jan. 30-Feb. 3 on the campus of the University of Clemson in South Carolina. DNSSEC Deployment Initiative member Scott Rose of the U.S. National Institute of Standards and Technology gave a DNSSEC tutorial on Sunday covering the basics of DNSSEC and showing the basic steps involved in signing a DNS zone.  The presentation slides are now available, and a netcast archive also will be posted.