DNSSEC Hits a Brick Wall

[Thierry Moreau <thierry.moreau@xxxxxxxxxxxxx>]

     DNSSEC Hits a Brick Wall

     Introduction

          With the publication of an expert panel's report
          [1] about the proposal [2] to deploy DNSSEC in the
          .org registry by PIR as the registry operator, a
          major obstacle is laid in the path to any
          significant DNSSEC deployment.

     Again, Trust Anchor Management Headaches

          This issue has been rehearsed again and again, and
          now comes up as an unfounded blame against PIR
          plans.

          Firstly, the panel puts the onus on the .org
          registry to deploy TA management procedures as if
          they were as exposed to criticism as ICANN would
          be as the root zone registry ("Many of the
          stability issues analyzed in this report would
          either not exist at all, or would be much more
          tractable, if the root were already signed."). PIR
          got no benefit from presence of DNSSEC deployment
          as an ICANN strategic plan item for the root zone.
          Reasonable expectations of security and stability
          from stakeholders should consider the special role
          of the root, and hence allow for some forgiveness
          towards TLD operations while the root isn't
          signed.

          The experts argue that the large size of the .org
          zone justifies more scrutiny, and application of
          specific criteria that would shift to the root
          zone DNSSEC operations once the root is signed.
          Because a new sTLD initiative specific to DNSSEC
          (e.g. a .trusted sTLD) would have virtually no
          chance to raise the required investment money
          given the current state of new TLD introduction
          process at ICANN, we may wonder that the **general
          availability** of DNSSEC registration services,
          rather than mere zone size, triggered the expert's
          scrutiny.

          More fundamentally, and this would apply to TA
          management for the root as well, the review panel
          ignored the inescapable fact that any TA rollover
          scheme has a catastrophic failure mode, including
          RFC5011 which is somehow touted as a better
          approach than PIR's. Stated otherwise, if PIR had
          elected to comply to RFC5011 [3], the panel would
          have inquired about the recovery policy for the
          simultaneous compromise of both the active and
          standby TAs, and PIR would have replied with the
          same language that led the panel to come up with
          its first principal finding. I know this, because
          if there was an attractive marginal security
          improvement in upgrading the simple PIR procedures
          to RFC5011, there would have been a similar
          attractiveness in my own TA rollover proposal
          which was turned down by experts with the same
          background as the panel members. The PIR proposal
          should not be turned down because you get into
          trouble if you lose the "master-master"
          cryptographic key.

          Likewise, the panel found that stability was at
          stake because the scheduled TA rollover creates a
          burden on DNSSEC-enabled resolver managers. If
          this is an issue at all, it belongs to the root.
          The panel seems to expect PIR to further the
          technology development that IETF DNSEXT and DNSOP
          concluded. DNSSEC is such that resolver management
          is slightly more demanding than plain DNS.

     The Registrar Business as a Negative Value Proposition

          In the Internet evolution, the registrar business
          segment has been created artificially for to
          introduce market competition in the DNS name
          registration at the retail level, leaving ICANN as
          a price regulator at the wholesale level (this
          applies to gTLDs and sTLDs but not directly to
          ccTLDs). It has always been obvious that the
          registrar function brings no added value to the
          DNSSEC deployment. The PIR proposal appears
          totally adequate for its side of the equation,
          i.e. in its disclosure of the provisioning systems
          made available to registrars interested in
          offering the service. When asked the minimum
          number of registrars offering DNSSEC-compliant
          registration service for the .org zone, PIR
          replied that two were a crowd. Why does the review
          panel assumes any PIR accountability in the
          commercial supply of registrar services? It is up
          to the registrants to ensure adequate sources
          before committing to DNSSEC, so PIR should not be
          bothered by the level of registrar enthusiasm.

     A Flawed Process from Day One

          In my opinion, the style of the ICANN RSTEP report
          may not be criticized without considering the
          inherent flawed process at its origin. From the
          inception of the ICANN Registry Services
          Evaluation Policy, I saw an elephant in the
          porcelain shop, but perhaps it's only me who
          doesn't understand why every aspect of simple
          organizational arrangements has to be re-invented
          because it's the Internet. A deliberative
          decisional process subject to dispute by
          interested parties isn't mankind leapfrog.  Simply
          stated, a case submitted to ICANN Registry
          Services Evaluation simply had to process in the
          classical phases, i.e. factual discovery,
          pleading, and deliberation leading to a written
          decision, followed by an appeal stage with
          suitable entry barriers. Technical experts brings
          educated opinions to the factual discovery phase,
          while opinions are usually deferred to the
          pleading phase. Add a few safeguards for
          independence and fairness, and a robust process
          design is done. A decisional process design may
          attempt to reduce formalities, but can hardly mess
          up with the basic structure. To me, the ICANN
          process is unbelievably remote from a logical
          arrangement.

          PIR was mislead in August 2006 when the ICANN
          chief gTLD liaison [4] suggested the evaluation
          process to be "a formality" "so long as PIR plans
          not to differ from the IETF standards and BCP
          guidelines". As a member of the public, I feel I
          was excluded from a fair and transparent fact
          discovery phase because the clarification
          questions asked by the panel to PIR were, as far
          as I know, undisclosed until the panel report
          disclosure. Even without much hindsight from the
          report findings, the timely disclosure of these
          questions would have triggered more input from the
          public.

          The report has been issued with a mix of factual
          findings and raw expert opinions but very little
          useful guidance for the next steps. The panel
          members were even reluctant to state that they
          felt authorized to recommend rejection of PIR
          plans if the factual base justified such a
          conclusion on the basis of security and stability
          alone; hence their main conclusion remains
          indeterminate. Moreover, a section of the report
          should have summarized the relative importance of
          various detailed issues raised by the experts. We
          may wonder how the ICANN staff will process the
          raw material and come up with an ICANN board
          recommendation. The report is merely ineffective.

          In a sense, the panel member applied an extensive
          security and stability criteria which was never
          envisioned by the protocol designers and the ccTLD
          registry operators which are not contractually
          bound to the ICANN registry services evaluation
          process. Neither the backwards compatibility of
          the DNSSEC protocol, nor the distributed nature of
          the DNS were taken into account in the proper
          identification of issues specifically under the
          control of the .org TLD registry. Aa a side
          effect, the report reveals the likely "security
          and stability" issues preventing the root from
          being signed.

          So, is ICANN in a position to make any progress
          towards general availability of DNSSEC to the
          global registrant's community? It is doubtful that
          any other gTLD or sTLD registry could go as far as
          PIR went in preparing for DNSSEC - PIR is the
          number two gTLD registry manager and demonstrated
          its organizational and technical leadership when
          it entered the business by winning the .org
          renewal bid from Verisign in 2002-2003. On the
          other hand, I guess Verisign business is dependent
          on its good standing in the US government
          perspective, and I don't expect .com or .net to
          turn DNSSEC compliant unless the Department of
          Commerce agrees to the general availability of
          DNSSEC, i.e. authorizes the root signature.

     Looking Beyond ICANN's Process

          Those involved in the formal process will act as
          they see fit, and we might expect the ICANN
          history to repeat itself.

          Independently, there are a number of signals that
          some forum would be needed to revisit the issue of
          DNSSEC trust anchor management and come up with a
          community consensus which could have more
          legitimacy than the ad-hoc panel. In fact, the PIR
          proposal itself hinted at this need: "Research is
          under way within the DNS community to automate the
          rollover of keys for DNSSEC." It is hard to tell
          exactly what is alluded by PIR as there is no
          visible momentum to support this statement, except
          for some type of acknowledgment that TA management
          should be revisited by the technical community.
          Admittedly, to the extent that PIR used this
          specific language, the RSTEP experts got some
          invitation to hammer the TA management issue. In
          my view, the TA management issue deserves a second
          look in an appropriate forum, but this should not
          postpone the DNSSEC deployment at the TLD level.
          This can be backed by technical arguments that
          would be in scope for a TA management forum work
          plan discussion.

     References

     [1]  ICANN Registry Services Technical Evaluation
          Panel, "Report on Internet Security and Stability
          Implications of the Public Interest Registry (PIR)
          DNSSEC Proposal", June 4, 2008,
          http://www.icann.org/registries/rsep/rstep-report-
          pir-dnssec-04jun08.pdf

     [2]  PIR, "Security Extensions for the DNS - DNSSEC",
          http://www.icann.org/registries/rsep/pir-request-0
          3apr08.pdf

     [3]  M. StJohns, "Automated Updates of DNS Security
          (DNSSEC) Trust Anchors", RFC5011, September 2007
          http://www.ietf.org/rfc/rfc5011.txt

     [4]  Letter from Tina Dam to Edward G. Viltz, re PIR
          DNSSEC Implementation, 14 August 2006,
          http://www.icann.org/correspondence/dam-to-viltz-1
          4aug06.pdf

--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@xxxxxxxxxxxxx