Last month, there was an exchange of letters between a gTLD administration and ICANN about DNSSEC deployment. This gTLD administration is PIR or Public Interest Registry, the gTLD administration for the .org TLD. Interestingly, PIR is a non-profit organization that makes significant contributions to ISOC (Internet Society) initiatives: thus, both ICANN and PIR are organizations dedicated to the well-being of the Internet.

The first letter was by PIR [PDF] and asked ICANN to “provide guidance on what coordination, approval and/or operational adjustments are required by ICANN in order for us to implement and deploy” the DNSSEC service. The answer [PDF] came as a reference to an approved Internet Draft entitled DNSSEC Operational Practices ([draft-ietf-dnsop-dnssec-operational-practices-08]) and a pointer to the ICANN Registry Services Evaluation Process (RSEP) [see Implementation Notes and Aug 30, 2006 annoucement]. The RSEP has just been finalized as the ICANN administrative process for considering new gTLD registry services. It allows gTLD administrations to request and obtain an authorization for introducing a new DNS registry service, including DNSSEC. The ccTLD administrations have a lesser obligation to follow the RSEP for the DNSSEC deployment since they are not contractually bound to ICANN.

What is the significance of the RSEP applicability to DNSSEC deployment by a TLD administration? This breaks down in three sub-questions:

• Was it to be expected that the RSEP applies to DNSSEC?
• Is it a trivial reporting task to meet the RSEP requirements for DNSSEC?
• Was it OK for ICANN to elude the root zone file signature issue (which would significantly benefit DNSSEC deployment by the TLD administration)?

Let’s consider this last sub-question. Suppose for a moment that the DNS root turns DNSSEC-compliant before the .org registry. Then, PIR, the .org registry administration, spares the DNSSEC trust anchor key management hindrance, but must comply with some operational rules for getting and maintaining a secure delegation in the DNS root zone file (that’s the basic motivation for signing the root in the first place). It would certainly have helped the PIR early planning for DNSSEC deployment to learn from ICANN that they are working hard towards such a scenario. Perhaps the intent of the written question by PIR was to clarify ICANN position in the specific area of obtaining a secure delegation in the DNS root zone file once it is signed. To this author at least, there is an element of surprise in the ICANN response to PIR.

About the two other sub-questions, we first review the RSEP:

• A TLD administration requesting authorization for a new registry service first fills a questionnaire with far-reaching and open-ended questions.

Implication for DNSSEC:
- it is questionable whether the TLD administration is in a position to determine the proper level of information details to be provided about its DNSSEC deployment plans, and
- in any event, not every question can be addressed by reference to approved Internet RFCs or current Internet drafts.

• Within 15 days after the TLD submits an RSEP request, ICANN determines whether the proposed service requires further review on the grounds of significant anticipated impact on either DNS security and stability, or competition (presumably someone in the ICANN staff would be delegated authority for this determination, and the RSEP allows the recourse to external expert advice).

Implication for DNSSEC:
- when making such a preliminary determination, an ICANN employee is likely to take a very conservative attitude.

• Unless the above preliminary determination tells otherwise, the RSEP request is studied by a team of five experts selected from a standing panel of 20, with a report on security and stability impact due within 45 days.

• Within 30 days of the RSEP report, the ICANN board should make a rejection or acceptance decision, with an opportunity for the requesting TLD administration to provide additional input to the board.

• Public comments opportunities are provided by the RSEP on the (perhaps redacted) TLD request and expert report.

The comprehensiveness of the RSEP questionnaire suggests that the RSEP represents a last-minute reality check for DNSSEC deployment, notably filling the gaps between the narrow interoperability-oriented IETF approach and the broader operational stability approach of ICANN. This is more than a simple bureaucratic formality. Basically, the exchange of letter shifts the onus of DNSSEC reality check from ICANN as the root zone administrator to the first gTLD administrations to deploy DNSSEC.

By contrast, the ccTLD independence from ICANN allowed the Swedish TLD administration to introduce DNSSEC support in the .se registry with a 12-month support commitment and in advance of complete suite of IETF RFCs.

In view of RSEP applicability to DNSSEC deployment, we can identify two sources of potential issues. Firstly, the limitations, both in scope and specifications refinements of the very DNSSEC security foundation leaves some potential stability and security issues, e.g.

• the absence of confidentiality service in DNSSEC raised a privacy concern which is being addressed as the NSEC3 pending specifications;
• the selection of DNSSEC NSEC3 operational parameters is left to the DNS registry operator, and is a potential source of security questioning;
• the denial-of-service (DOS) prevention is also out-of-scope of DNSSEC, but there are recent reports of DOS “amplification attacks” exploiting the larger DNSSEC-aware response size;
• since ICANN endeavors to induce root nameserver to follow operational practices per IETF RFC2870, will it expect TLD registry operators to document its DNSSEC operations to the same level of details;
• the Trust Anchor Key management is another area where DNSSEC specifications requirements are outstanding, and for which the logical approach would be to leave the onus of reality check with ICANN (this is in direct connection with the DNSSEC support at the root, or “signing the root” issue discussed earlier).

Secondly, the registrar-registry interface needs an upgrade for DNSSEC deployment support. This author is less knowledgeable of this potential source of RSEP issues, but the following aspects seem to be covered by the questionnaire:

• interoperability protocols,
• business model,
• contractual provisions.

In summary, the reply letter from ICANN to PIR links DNSSEC deployment by gTLD administrations to the just finalized Registry Services Evaluation Process, and raises the bar for DNSSEC deployment planning in the form of additional documentation requirement, ahead of implementation experience. In the meantime, the Internet community got no indication of ICANN commitment to support DNSSEC at the root.