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.

Reflecting on the 25th anniversary this week of the Internet Engineering Task Force (IETF), chair Russ Housely pointed to DNSSEC and IPv6 as two standards that represent the group’s strength in anticipating needed standards. He told Computerworld:

Sometimes the IETF sees a need before the marketplace is ready to embrace it. This leads to the standards being in place before the service providers are ready to deploy. DNSSEC and IPv6 are two examples. So working on global deployment of these completed protocols to offer new capabilities is one challenge. Yet the capabilities offered by these protocols is necessary for the continued growth of the Internet as a trusted platform for communications and innovation used by billions of people around the world.<!—->

Responding to a presentation by Dan Bernstein in which “much of his representation of DNSSEC — and his own replacement, DNSCurve — was plainly inaccurate,” security research Dan Kaminsky offered a thorough tutorial about DNSSEC that addressed some of the interpretations and in the Bernstein presentation.

Kaminsky notes that the Bernstein presentation is  “actually a pretty good summary of a lot of latent assumptions that have been swirling around DNSSEC for years — assumptions, by the way, that have been held as much by defenders as detractors.”

DNSSEC’s Problem With Key Rotation Has Been Automated Away
DNSSEC Is Not Necessarily An Offline Signer — In Fact, It Works Better Online!
DNS Leaks Names Even Without NSEC3 Hashes
NSEC3 “White Lies” Entirely Eliminate The NSEC3 Leaking Problem
DNSSEC Amplification is not a DNSSEC bug, but an already existing DNS, UDP, and IP Bug
DNSSEC Does In Fact Offer End To End Resolver Validation — Today
DNSSEC Bootstraps Key Material For Protocols That Desperately Need It — Today
Curve25519 Is Actually Pretty Cool
Limitations of Curve25519
DNSCurve Destroys The Caching Layer.  This Matters.
DNSCurve requires the TLDs to use online signing
DNSCurve increases query latency
DNSCurve Also Can’t Sign For Its Delegations
What About CurveCP?
HTTPS Has 99 Problems But Speed Ain’t One
There Is No “On Switch” For HTTPS
HTTPS Certificate Management Is Still A Problem!
The Biggest Problem:  Zooko’s Triangle
The Bottom Line:  It Really Is All About Key Management

VeriSign announced this week that Arbor Networks, Infoblox and RioRey have completed testing their technology solutions in the VeriSign DNSSEC  Interoperability Lab, which evaluates “how equipment will interoperate in a DNSSEC-enabled environment.”  A10 Networks, BlueCat Networks, Brocade, Cisco Systems and Juniper Networks also have tested their solutions in the lab.

The company also announced it is introducing a new iPhone app, DNSSEC Analyzer, described as a “mobile tool that can assist in diagnosing problems with DNSSEC-signed names and zones. The application will allow a quick diagnosis of any domain name, allowing knowledgeable users to view debugging information and receive useful tips on how to remediate any problems that are discovered.”

VeriSign is expected to complete DNSSEC deployment in .com by the end of the first quarter of this year.  Go here to find more on its efforts to assist DNSSEC deployment.