FAQ about

Trust Anchor Key REnewal Method (TAKREM)

for DNSSEC


Updated on 2006/05/10



 

1.Background

Q1.1What is TAKREM for DNSSEC?

Q1.2What is a Trust Anchor Key?

Q1.3What is DNS, DNSSEC, and Trust Anchor Key Management?

Q1.4Why DNS SECurity Extensions?

Q1.5Who Needs DNS SECurity Extensions?

 

2.TAKREM for DNSSEC

Q2.1What Is an Automated Trust Anchor Key Rollover Procedure?

Q2.2Where Does TAKREM for DNSSEC Fit?

Q2.3How Good is TAKREM for DNSSEC?

Q2.4What Are the Alternatives to TAKREM for DNSSEC?

 

3.TAKREM for DNSSEC Specifications Status

Q3.1Where are the official protocol documents?

Q3.2Where are the security oriented documents?

Q3.3Is There a TAKREM for DNSSEC Demonstration Implementation?

Q3.4What is the Basis for Internet Community Adoption of TAKREM for DNSSEC?

 

4.TAKREM Intellectual Property Status

Q4.1What is the patent status of TAKREM?

Q4.2Is the TAKREM Patent a Software Patent?

Q4.3To Which Extent Does DNSSEC Depend on TAKREM?

Q4.4Can TAKREM be Licensed as Other Essential Patents for Open Standards?

 

5.TAKREM Licensing Framework Overview

Q5.1Aren't Patents Incompatible with Open Source Software?

Q5.2How are DNS Zone Managers Impacted by TAKREM Licensing?

Q5.3How is DNS Resolving Impacted by TAKREM Licensing?

Q5.4How is Software Distribution Impacted by TAKREM Licensing?





1.     Background


Q1.1  What is TAKREM for DNSSEC?


TAKREM stands for Trust Anchor Key REnewal Method. It is a process for Internet security support functions, comprising technological aspects (data protocol specifications) and procedural aspects (directives for manual operations). TAKREM is proposed for application to DNS security enhancements known as DNSSEC.


Q1.2  What is a Trust Anchor Key?


A trust anchor key is a type of cryptographic key. That is, information technology security (including Internet security) often relies on cryptographic techniques, which invariably use cryptographic keys, and a trust anchor key is a cryptographic key characterized by its unique position in a key management scheme. Specifically, a trust anchor key is a public key, usually in a digital signature scheme based on public key cryptography, that is widely distributed and trusted to belong solely to a trusted central organization.


Trust anchor keys exist today in Internet browser configuration as the public keys indicated in trusted CA certificates (OK, very few users are aware of trusted CA's in the first place, but they indeed contain trust anchor keys in the X.509 PKI technology). Trust anchor keys are an explicit requirement of the DNS security protocol extensions, DNSSEC.


Q1.3  What is DNS, DNSSEC, and Trust Anchor Key Management?


The DNS is the Domain Name System which provides a “master directory” for the Internet. It is an Internet service that has been operational since the inception of the network. The DNS is based on protocol specifications known as Internet RFC (Request For Comments) finalized in 1987.


The acronym DNSSEC refers to DNS SECurity extension, i.e. supplemental protocol specifications that were first issued as RFCs in 1999, with an important revision in 2005. Actual DNSSEC deployment is still very limited, and a few DNSSEC protocol refinements are still outstanding, including in the area of trust anchor key management. The DNSSEC protocol brings cryptography-based data assurance to the DNS, with a corresponding participants education challenge. DNSSEC uses the public key cryptography digital signature technology.


Trust anchor key management refers to the procedures for first establishing, and renewing thereafter, the trust anchor keys that are mandated by the DNSSEC protocol specifications. A DNSSEC trust anchor key is a digital signature public key used for DNSSEC data assurance validation. Actually the DNSSEC protocol specifications require trust anchor key management procedures, yet leaves them unspecified. A trust anchor key management scheme invariably adds some manual procedure instructions (sometimes implicitly) to provide overall DNSSEC data assurance. -- Trust anchor key management is like a small blind spot in the DNSSEC technology, notably because no trust anchor key management scheme can be based solely on technological means.


\-------------------------------------------/

|\-----------------------------------------/|

||        DNS (Domain Name System)         ||

||                                         ||

||  +-----------------------------------+  ||

||  |  DNSSEC (DNS SECurity extension)  |  || core DNS data

||  |                                   |  || protocol

||  |      +.....................+      |  ||

||  |      .  TAK (Trust Anchor  .      |  ||

||  |      .  Key) management    .      |  ||

|/--|------.---------------------.------|--\|

/---|------.---------------------.------|---\

    |      .                     .      | cryptography assisted

    |      .                     .      | data assurance

    +------.---------------------.------+

           .                     . manual security

           .                     . procedures

           +.....................+


Q1.4  Why DNS SECurity Extensions?


The computer security textbook justification for DNSSEC is the lack of cryptographic data assurance in the plain DNS. This leaves a vulnerability of Internet communications to various types of attacks, e.g. in the area of phishing, which are becoming more serious as the reliance on Internet increases and the hackers become more sophisticated.


Q1.5  Who Needs DNS SECurity Extensions?


Based on the need to provide cryptographic data assurance for data retrieved from the DNS, any e-commerce and e-government operator should be pleased by the advent of a more secure DNS.


Another target user group for DNSSEC services is the potential users of application security schemes which rely on a secure DNS for application-oriented public key distribution. Applications in this category are just emerging, such as spam prevention schemes (a candidate killer application for DNSSEC?) and encryption schemes with a DNS-centric key distribution strategy.


Participants in the DNS service operations, such as domain name registrars, may consider the DNSSEC adoption within a market differentiation strategy, or a value-added service opportunity.


Overall, it seems difficult to predict a significant demand for DNSSEC deployment from any of the qualitative demand factors just identified. This may seem familiar to long-term observers of the IT security landscape.





2.     TAKREM for DNSSEC


Q2.1  What Is an Automated Trust Anchor Key Rollover Procedure?


For the purpose of DNSSEC support, trust anchor key management has three main components:

  o         the initial distribution of trust anchor key material to every DNS resolver system configuration,

  o         an automated trust anchor key rollover procedure, allowing DNS resolvers to use a new trust anchor public signature key, and

  o         other key management operations that may actually be omitted from DNSSEC capabilities due to specifics of the DNS operational environment, e.g. a trust anchor key compromise alert message can not be reliably delivered to DNS resolvers.

Actually, a good automated trust anchor key rollover procedure is a much wanted DNSSEC protocol refinement, i.e. a procedure which would be secure without end-user or resolver system operator action, occurring quietly in the background of regular DNS (and DNSSEC) protocol exchanges. Moreover, a rollover scheme may provide some auxiliary facilities for other key management operations.


Q2.2  Where Does TAKREM for DNSSEC Fit?


TAKREM for DNSSEC relies on initial distribution of trust anchor key material using an out-of-band distribution channel (e.g. inclusion in default configuration in DNS browser software distributions), and provides an automated trust anchor key rollover procedure. In addition, TAKREM for DNSSEC rollover is secure and fully automated. Scheduled trust anchor rollovers are supported with an explicit cryptoperiod affixed to a trust anchor key. Emergency trust anchor rollovers are supported to the extent allowable by the DNS operational environment.


Q2.3  How Good is TAKREM for DNSSEC?


Very good. Actually, TAKREM for DNSSEC is the single good TAK management solution currently proposed.


Q2.4  What Are the Alternatives to TAKREM for DNSSEC?


There are three sources of inspiration for trust anchor key rollover solutions, namely

   1)      ad-hoc procedures,

   2)      DNS protocol extensions attempts, and

   3)      specific adaptations of cryptographic mechanisms to trust anchor key rollover,

TAKREM for DNSSEC falling in this last category.


Ad-hoc procedures would include long-lasting trust anchors that are intended to almost never roll, or ideas such as publishing trust anchor keys in an SSL-backed web site.


DNS protocol extensions attempts include a timers-based scheme [1]. Like other attempts in this category, the security foundation rests on after-the-fact analysis of the protocol provisions, with uncertainty in the end-result.


The TAKREM proposal is the only specific adaptation of cryptographic mechanisms to trust anchor key rollover for DNSSEC. Other schemes in this category might include a “master signature key” for rollover purposes, or a scheme originally designed for secure electronics transactions [2], but neither of these approaches has been adapted for DNSSEC support.

 

[1]       M. StJohns, Automated Updates of DNSSEC Trust Anchors, internet draft draft-ietf-dnsext-trustupdate-timers-02.txt, January 10, 2006, archived at http://www.watersprings.org/pub/id/draft-ietf-dnsext-trustupdate-timers-02.txt

 

[2]       Tony Lewis; Key Replacement in a Public Key Cryptosystem, United States Patent no. 6,240,187, issued on May 29, 2001, assigned to Visa International, filed on February 10, 1998.





3.     TAKREM for DNSSEC Specifications Status


Q3.1  Where are the official protocol documents?


Currently, the TAKREM for DNSSEC specifications are available as two “Internet Drafts” [3], [4]. As a publication mechanism, Internet Drafts are somehow defective: an Internet Draft is a temporary documents with a six-months expiry period, that should be referred to as “work-in-progress.” The six-month life expectancy of an Internet Draft is enforced by the official RFC editor, but expired Internet Drafts are archived by a number of other organizations, which is important for the Internet community, both for historical purposes and for establishing “prior art” for countering novelty claims by would-be inventors of old stuff.


As work in progress, these Internet Drafts should evolve into either Internet RFCs or another form of permanent publication which could be referred by Internet documents as “external specifications.”

 

[3]       Thierry Moreau, The SEP DNSKEY Direct Authenticator DNS Resource Record (SDDA-RR), Internet Draft draft-moreau-dnsext-sdda-rr-02.txt, April, 2006, archived at http://www.watersprings.org/pub/id/draft-moreau-dnsext-sdda-rr-02.txt

 

[4]       Thierry Moreau, The Trust Anchor Key Renewal Method Applied to DNS Security (TAKREM-DNSSEC), Internet draft, draft-moreau-dnsext-takrem-dns-02.txt, April, 2006, archived at http://www.watersprings.org/pub/id/draft-moreau-dnsext-takrem-dns-02.txt


Q3.2  Where are the security oriented documents?


The TAKREM for DNSSEC proposal is a security procedure, including technological components and procedural steps. The introduction of DNSSEC adds a security dimension to the plain DNS, and a trust anchor key rollover procedure goes further in this direction. The security rationale for the core TAKREM procedure is found in [5]. In its adaptation to the security of DNS, some additional security functions are provided, notably for trust anchor cryptoperiod management, which are not documented outside the protocol documents indicated in the preceding question.

 

[5]       Thierry Moreau, A Note About Trust Anchor Key Distribution, CONNOTECH Experts-conseils inc., Document Number C003444, 2005/07/05, http://www.connotech.com/takrem.pdf


Q3.3  Is There a TAKREM for DNSSEC Demonstration Implementation?


Yes, there is a TAKREM for DNSSEC demonstration implementation. It is proposed as software development notes and sample source code for implementing TAKREM for DNSSEC in a DNS software which already supports DNSSEC. See reference [6].

 

[6]       http://www.connotech.com/takrem_tools/trust-anchor-foundry_02.tar.gz


Q3.4  What is the Basis for Internet Community Adoption of TAKREM for DNSSEC?


Answer: the need to perform a sensible procedure for trust anchor key rollover at the DNS root and TLD level, once the DNSSEC protocol is deployed, given that such rollover procedure is a basis for public confidence in the trusted central organization.


CONNOTECH is committed to make available an automated trust anchor key rollover procedure that fits the DNS root and TLD operational environment, and the current Internet Drafts are reflective of this effort.


Exactly how the Internet community adoption can proceed is beyond the scope of the present FAQ.





4.     TAKREM Intellectual Property Status


Q4.1  What is the patent status of TAKREM?


TAKREM is a patent-pending solution. The application reference is [7].

 

[7]       Thierry Moreau, Trust Anchor Key Cryptogram and Cryptoperiod Management Method, Canadian patent application number 2,511,366, filed on June 30, 2005, http://patents1.ic.gc.ca/details?patent_number=2511366&language=EN


Q4.2  Is the TAKREM Patent a Software Patent?


Not exactly. The TAKREM invention consists of three interoperable processes, reflecting the operations related to trust anchor key management in the DNSSEC application area, i.e.

  1)       a procedure for trust anchor public key initial configuration, done by DNS zone managers,

  2)       a procedure for the trust anchor rollover announcement, done by DNS zone managers, and

  3)       a procedure for the trust anchor rollover validation, done in DNS resolvers.

This arrangement is also reflected in the TAKREM licensing framework.


Q4.3  To Which Extent Does DNSSEC Depend on TAKREM?


For DNSSEC protocol design completion, an automated trust anchor key rollover is a recognized requirement. However, the DNSSEC protocol deployment faces a quite broad set of challenges, of which the trust anchor key rollover is a small portion. Thus, the past and anticipated slow progress of DNSSEC is not caused by the TAKREM patent issue.


In other words, there is not enough momentum for moving DNSSEC from the laboratory to the field in the first place, so the TAKREM patent issue is not yet a priority for important stakeholders. This may change in the future.


Q4.4  Can TAKREM be Licensed as Other Essential Patents for Open Standards?


TAKREM for DNSSEC is an atypical case of an essential patent required for an open standard. This is because the patent holder is a very small organization and the potential users of the patent are primarily DNS zone managers at the root and TLD level, i.e. organizations who already operate on a volume-based fee structure.


The typical case of an essential patent required for an open standard can be described briefly. The R&D department of a large firm develops portions of open standards, and file patent applications when a genuine invention is being made. The resulting patent portfolio is licensed with “field of use restrictions” and “reciprocity requirements” that basically protects the large firm from patents claims by third parties for its own implementation of the open standard, and reserves the patent commercial value in non-standard fields of use. The reciprocity principle creates a patent pool among major contributors, that would remain a closed group (as happened with the first generation cellular telephony technology from which Japanese manufacturers were excluded, [8]), if the standard drafting organizations did not insist on “non-discriminatory” licensing. A medium or small firm has little incentive to assert intellectual property rights on a standard improvement if it collects revenues from an implementation of the plain open standard, whenever the latter is already targeted by a reciprocity license provision. So, the typical essential patent licensing for open standards protects the large firms against IPR assertions by smaller firms.

 

[8]       Bekkers, Rudi and Liotard, Isabelle, European Standards for Mobile Communications: The Tense Relationship between Standards and Intellectual Property Rights, European Intelectual Property Review, 1999; 21 (3), pp 110-126





5.     TAKREM Licensing Framework Overview


Q5.1  Aren't Patents Incompatible with Open Source Software?


Early in the TAKREM promotion campaign, a decision has been made to allow GPL version 2 software implementation of the TAKREM patent-pending processes. This is a genuine contribution to the open source software model in which proprietary diversion of open source contributions (“proprietary fork”) is prevented by a specific copyright license. This license donation has been done in acknowledgment of the legitimate need for open source implementations of protocols.


The details of the legal arrangements for GPL version 2 software implementation of the TAKREM processes, see [9]. These details were discussed with the Free Software Foundation staff via e-mail exchanges.


If the DNS service in the global Internet was totally operated with the GPL open source model, the TAKREM intellectual property rights would have little commercial value. This is not expected to happen soon since many major players in the DNS service rely on private and/or IPR protected protocol implementations (including proprietary forks of the BIND software). In this context, the reader may take note of the PowerDNS software [10], as a DNS software implementation licensed with the GPL model. However, PowerDNS currently lacks DNSSEC support, which is representative of the lack of demand for DNSSEC.

 

[9]       CONNOTECH Experts-conseils inc., Unilateral and Conditional Patent License, dead of deposit before Me Fabien L'Heureux, Notary for the Province of Québec, 40, chemin Bates, room 126, Outremont, Québec, Canada H2V 4T5, from whom a certified copy may be obtained by quoting the file number 1418 (dated October 22nd, 2005) as a reference

 

[10]     http://www.powerdns.com/


Q5.2  How are DNS Zone Managers Impacted by TAKREM Licensing?


The licensing framework should be coherent with the purpose of TAKREM for DNSSEC, i.e. providing assurance about data retrieved from the DNS distributed database. The core principle of the licensing framework is to allow the publisher of DNS data to settle the license compliance requirements on behalf of the user community.


For non-root DNS zone operations, there are two ways to become DNSSEC-aware: either as a normal secure zone having a secure delegation from a secure parent, or as an island of trust. For the DNS root and islands of trust, a TAKREM for DNSSEC license is required according to the licensing framework. Some details are provided in reference [11].

 

[11]     Thierry Moreau, Technology Licensing Framework for Automated DNSSEC Trust Anchor Key Rollover, CONNOTECH Experts-conseils inc., Document Number C003725, 2006/04/10, available upon request from the author organization


Q5.3  How is DNS Resolving Impacted by TAKREM Licensing?


The licensing framework is focused on licenses paid by DNS zone managers for trust anchor key rollover announcements, so there would be no DNS resolver licensing requirement in the usual case where the DNS zone is a “licensed DNS zone.” Some details are provided in reference [11].


Q5.4  How is Software Distribution Impacted by TAKREM Licensing?


There is currently no plan for software product claims associated with the TAKREM processes, so distribution of DNS software would not be threatened by the TAKREM patent protection. It is the users of DNS software that might need to address the licensing issues. Some details are provided in reference [11].





[ CONNOTECH home page: http://www.connotech.com | e-mail to: info@connotech.com ]




CONNOTECH Experts-conseils Inc.

9130 Place de Montgolfier

Montréal, Québec, Canada, H2M 2A1

Tél.: +1-514-385-5691

Fax: +1-514-385-5900