Last week, VeriSign and ICANN presented some fairly detailed information about signing the root zone using DNSSEC, the DNS Security Extensions. The Department of Commerce had previously announced that VeriSign and ICANN would jointly administer the signed root, but until yesterday it wasn’t clear (to me, anyway) how their responsibilities would be divided. At RIPE 59 in Lisbon, Joe Abley of ICANN and Matt Larson of VeriSign (yes, my former business partner and the other half of “The Ask Mr. DNS Podcast”) talked about the division of labor.
Basically, as I understand it, ICANN will be responsible for managing the Key-Signing Key and VeriSign for the Zone-Signing Key. Recall that in most DNSSEC-signed zones, there are two key pairs. One key pair is used for signing the zone data, while the other is used to sign just the zone’s keys. There are several advantages to this arrangement: The parent zone validates the Key-Signing Key, or KSK, which in turn validates the Zone-Signing Key, or ZSK. Thus when the ZSK must be rolled over – which happens more frequently than the KSK, because more data is encrypted using the ZSK – the parent zone need not be informed; the administrator can simply re-sign the new ZSK using the existing KSK. Also, the ZSK can be shorter than the KSK. This means that most of the signatures in a zone are shorter (because they’re signed with the ZSK) and therefore don’t result in such large responses and don’t take as many computational resources to validate, but the entry point to the zone, the KSK, is still difficult to attack cryptographically.
ICANN will also be responsible for accepting keys for subzones of the root (i.e., top-level zones), verifying those and requesting that VeriSign sign them using the ZSK.
Even more important to many of us was the timeline for signing the root zone: The zone will be signed by December 1 of this year, although that version of the zone will initially remain internal to ICANN and VeriSign. However, as early as January of 2010, the incremental rollout of the signed zone will begin, and by July 1 the signed root zone will be fully deployed.
Why does this matter to you? If you’re deploying DNSSEC, the existence of a signed root zone makes your job much easier. Without a signed root, you’d need to configure your recursive name servers with the public keys of all top-level zones that you’d like to validate. There are already nine top-level zones that have been signed and more on the way, so configuring those public keys and keeping them up-to-date is no trivial task. With a signed root, all you need in order to validate signed data from any of those top-level zones is the public key (the public half of the KSK) of the root zone configured on your name server. Easy!
