Document Number C004692
Copyright (C) 2008 CONNOTECH Experts-conseils inc.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Specifications subject to change without notice.
Table of contents
There is no doubt the earliest opportunity is the proper time for action in DNSSEC deployment. The present NTIA Notice of Inquiry [NTIA_NOI] is thus welcome and the opportunity to reply is very much appreciated.
DNSSEC support at the root will be a significant development in the Internet history as the first fielding of a public key digital signature mechanism with a global applicability. Both the PKI (Public Key Infrastructure) and the LDAP (Lightweight Directory Access Protocol) technologies were once envisioned with similar global applicability, but neither were implemented as originally intended.
This very DNSSEC global applicability motivates the present comment submission, which is focused on cryptographic key management issues, mainly as they relate to the organizational aspects of authoritative root zone management. Basically, our claim is that given a reasonable organizational arrangement (requirements), we are able to contribute to cryptographic key management guidelines (solution elements) that would allow better use of cryptographic techniques in the specific context of the NOI document.
Overall, the information provided by NTIA in the NOI document plainly delineates the scope of the issues, their relevance, available options. In doing so, it suggests a willingness to proceed diligently with the DNSSEC implementation a the authoritative root zone management level.
The present author has been involved in various aspects of cryptographic key management since 1994, and since 2005 in support of DNSSEC. Foremostly, this involvement includes a general dedication to the proper adaptation of cryptographic key management schemes to operational and organizational arrangements. On many occasions, the present author reminded an audience that cryptographic mechanisms do not control information; they merely shift information controls into fewer hands. This principle applies to the subject matter of the present NOI: the RKO (Root Key Operators) are essentially these few hands holding the DNS integrity controls.
The US government oversight of the Domain Name System is a much debated issue. The NTIA is indeed part of the executive branch of the US government. In this subsection, we make some simplifying observations about the expectations of DNS root key management strategies by NTIA. In our attempt to simplify, there are only two classes of stakeholders:
The above is a simplification only because stakeholder expectations are not always logical. Some may see some special status affixed to the role of RKOs. Mistrust directed at government controls may be extended to the technical control of the DNSSEC integrity scheme under unspecified justification or mere paranoia. Confusion may arise with other internet governance issues that are more sensitive to differentiated stakeholder expectations, e.g the enforceability of trademark rights in the Internet domain namespace. Superfluous expectations may come from a wrong understanding of the the DNSSEC technique as a confidentiality mechanism, while DNSSEC is actually limited to an integrity function. We ignore these grounds for making DNSSEC more policy-intensive than we see fit.
Thus, for the vast majority of stakeholders, the DNSSEC deployment strategies at the root need not challenge the US Principles on the Internet's Domain Name and Addressing System (reference 19 in the NOI document). Although the NOI may not be the proper place to make observations that are not aligned with these principles, we take such liberty when our discipline of adapting key management to organizational issues suggests so. As hinted above, this will occur in relationship with the perspective of strategically-concerned stakeholders.
Generally, there is an assumed expectation of RKO dedication to state-of-the-art IT security technologies and compliance to adequate procedures. The present comment submission does not review this generic security requirement. The proposals by ICANN and Verisign, respectively (references 25 and 26 in the NOI document) seems fairly comprehensive in this respect. The generic security requirement and the criticalness of DNSSEC root keys introduce the issue of RKO accountability. To the extent the accountability aspect creates concerns with the assignment of DNSSEC root operational responsibilities, it may be noted that the NTIA as a US government entity happens to have the right accountability relationship with US federal government agencies as DNSSEC relying parties, a self-service arrangement not nominally available to other national governments.
We now try to describe what strategically-concerned stakeholders could logically fear if the RKOs are subverted. The good news for everyone is that it's a vulnerability totally devoid of attractiveness for would-be fraudsters even if it could be implemented in a DNSSEC island of trust other than the root. We describe it merely to indicate how a strategically-concerned stakeholder may remain unsatisfied even if the RKO arrangement is fully satisfactory with respect to the generic security requirements in the preceding paragraph. Basically, we are referring to a targeted integrity attack on the assumed integrity provided by DNSSEC. Any non-targeted attack would be noticed as the root nameservers are very public. The victim is a relying party that relies on DNS data in a DNS zone like
cfo.headquarters.example.org such that spoofed data could have a severe impact also desirable to an adversary who subverted the RKOs. The adversary obtains a signed version of the root zone file that is authoritative for
cfo.headquarters.example.org and proactively spoofs DNS replies to queries from the victim's systems. The attack success depends on an inordinate extent of required protocol hacking, nameserver replication, and cache defeating tricks. It is nonetheless worth a description in here as the single logical base known to us for strategically-concerned stakeholders to object to a DNS signed root "under control" of the US government. In the final analysis, the wrong behavior that could be suspected from the RKOs given the cryptographic machanisms is so remotely applicable that only the RKO accountability issue appears relevant.
The DNSSEC deployment at the root implies some unique tchnological requirements that are derived more from the uniqueness of the root in the distributed DNS hierarchy than from the DNSSEC protocol details.
Among the best practice security procedures, split or dual control of important cryptographic key material is an inescapable requirement. Nowadays with the use of PKC (Public Key Cryptography) in highly automated network services, the split control of key mterial may not appear as a foremost requirement, but its ever-present justification is intact in the case of DNSSEC root keys. In practice, the requirement enters the DNSSEC root deployment as the control mechanism to either inject or enable the KSK (Key Signing Key) into an HSM (Hardware Security Module) for off-line KSK digital signatures. Whether it is implemented as a split knowledge technique for the private key value, as a token-based access control for turning the HSM unit into an operational state, or as a multi-signature scheme for RSA, the operational principle is the same.
Note that the ZSK need not be subject to split or dual control. It is the very purpose of an emergency ZSK rollover procedure, applying KSK signatures, to make ZSK compromise recovery possible without re-configuration of the whole population of DNS resolvers.
Operationally, failure to properly implement split or dual control of important key material such as the root KSK puts a person in the position of a single point of failure. With the transparency of procedures that every party is advocating for the DNSSEC root signature operation, such a failure is not an option. Note that the justification is a matter of RKO accountability, and not a matter of mitigating any excessive "power" associated with the RKO role. The two remaining questions are
The first question will be addressed below when looking at the institutional arrangements. In reference to the process flows detailed in the NOI document, we just observed that the differentiated characteristics of the 6th one should be applied somehow to any process flow solution, so the first 5 should be amended accordingly and compared using other decision criteria.
Essentially, the RKO role comprises
The ZSK rollover operations is essentially a delegation of signing authority to the DNS expert personnel in charge of the authoritative root zone file change management, which is a highly visible activity watched by DNS experts throughout the world. With the exception of the DNSKEY root RRset (the set of public signature keys for authoritative root zone file), no inspection or handling of DNS data is required. Thus the technical quality assurance does not rest critically on the RKO oversight. Some institutional quality assurance or audit function should be part of the RKO role definition.
The most technology-intensive portions of the RKO role are the initial KSK generation and scheduled KSK rollovers. Ideally, the RKO "entities" should be autonomous in these activities instead of relying on the DNS experts so they are less vulnerable to "social engineering attacks," i.e. being misdirected into undesirable KSK handling operations by the very individuals responsible for the activities delegated by the RKO. To make things more puzzling, it is not even clear that suitable secure systems and devices are available commercially for the DNSSEC root KSK handling. The HSM suppliers have product line offerings with token-based split or dual control of digital signature capabilities, but the DNS root KSK application may require more transparency and independent public audit than vendors would accept. Also, the threshold split control of digital signatures could be on some vendors' catalog but never actually deployed by customers (we never encountered a public or confidential report of threshold scheme actual usage). The root KSK digital signature technology procurement effort should also account for technology obsolescence since the lifetime of rolled-over root KSKs is expected to span beyond the typical product life-cycle in specialized electronics products.
Reader's note: this subsection uses more acronyms and specialized terms than the rest of the document, without systematically explaining them.
The two preceding subsections apply the IT security technology such that the DNSSEC root KSK processes are adequately protected, notably by classical separation of duties. Similar separation of duties arrangements would be needed if the DNSSEC root KSK management was to rely on [RFC5011] with the intent to formalize scheduled KSK rollovers and emergency KSK rollovers, the latter being effective in the case of security breaches occurring in a subset of the two or more entities participating in the separation of duties arrangement.
We see no justification for [RFC5011] reliance. Serious process inefficiencies would occur if [RFC5011] reliance would be in addition to the separation of duties for split or dual control of KSK private key. Seemingly, the other option is the [RFC5011] reliance as a replacement for the separation of duties for split or dual control of KSK private key. However, we are not aware of any DNS security expert recommendation for such a strategy for any island-of-trust, notably the root (a qualified recommendation would explicitly refer to the operational aspects of the separation of suties).
For the vast majority of Internet users, it will be more important to enjoy continuous smooth DNSSEC operations when there is no root KSK security breach than to get improved assurance that some type of root KSK security breach may be recovered automatically. In practice, any detectable or publicly known root KSK security breach would make the headlines in IT sector media quicker than the typical DNS resolver operator reaction time to a cryptic log message.
At this point in time, the root zone management has a discretionary decision opportunity about DNSSEC root zone KSK management. This observation comes from the lack of consensus or widespread requests from the part of early DNSSEC adopters for [RFC5011] support by DNSSEC island-of-trust zone managers. The limit to the discretionary decision is the minimal root KSK management sophistication that would still allow DNS resolvers to automatically update their root trust anchor state when a scheduled KSK occurs (for which a need is widely recognized). There is thus a back-and-forth interplay of DNS resolver community expectations and root zone management commitments. As a starting point, we suggest the following DNS resolver behavior as a model for a typical DNS resolver.
A very robust DNS resolver software behavior (assuming recovery of KSK security breaches need not be automated) is specified in three simple rules:
This should work when the DNSSEC island-of-trust implements simple ad-hoc KSK rollover procedures and [RFC5011] as well.
We suggest a formalization of the above paragraph as representative of the initial NTIA commitment as a root zone manager participant. Unless otherwise told, NTIA may assume that the vast majority of DNSSEC resolver operators would be satisfied with this level of commitment with respect to automated KSK rollovers.
Institutional arrangements for RKO entities are easy to derive from the above section "2.1 Split or Dual Control of KSK Private Key" and the advocated correspondence between key management and organizational issues. In this perspective, the RKO entities should be employees or agents of NTIA as a direct consequence of the following citation from the NOI document: "As with other changes to the root zone, the Administrator would be responsible for verifying/authorizing updates to the root keyset." Since responsibility and operational control allocations should match, and since root keyset signature is controlled by the RKOs, RKO entities should act on behalf of the Administrator, i.e. NTIA.
We are not in a position to suggest whether NTIA employees or agents are more appropriate. Maybe the selection of agents by NTIA would exhibit increased transparency and accountability. By NTIA agents, we mean organizations or individuals acting with the same mission definition as the NTIA but without direct supervision by NTIA (or DOC?) management. Professionals governed by their profession code of conduct could fit the definition. Without much clues about how likely are interagencies arrangements in the US government, we think other divisions of the US government executive branch might qualify as RKO entities, e.g. from GAO, Finance, Justice, other DOC divisions, or a division of another department having the operational responsibility of a PKI certification authority. Entities outside of the US government might not be sufficiently bound to the US Principles on the Internet's Domain Name and Addressing System (reference 19 in the NOI document).
The idea of linking KSK key custodians to the Administrator accommodates the long term perspective implicit in the NTIA oversight of the Internet naming and addressing system. In contrast, both the IANA Function Operator and the Root Zone Maintainer have an operational horizon aligned with the shorter terms of their respective contracts. The alignment of RKO role allocation to these time horizons reduces the Internet community blind faith in the continued operation of current holders of the IANA function or root maintenance roles.
The figure shows the process flow corresponding to the above observations. In essence, this is the NOI document process flow number 5 except that the KSK operations are located in the Administrator facilities instead of collocated with the Root Zone Maintainer facilities. The position of the multiple key custodians is now shown on the figure, except collectively by the yellow hatching rectangular area surrounding the "Generate KSK" and "Sign Keyset" functional blocks.
The process flow characteristics suggested above are offered to NTIA and the Internet community as a bona fide effort using the terms and perspective of the NOI document. In the process of finalizing them, a few limitations were noticed that could be addressed with the submission of TAKREM for DNSSEC as the base for a different process flow.
The limitations to the above process flow are listed here:
Thus, an annex to the present contribution document [ANNEX] has been prepared to make sure the option once promoted by the present author organization remains available for further investigation of the DNSSEC root deployment.