IT security specialists have known for years that the plain DNS is not to be trusted. Any hope for improvement rests on the DNSSEC protocol deployment. In this post, I will review the current status in one critical aspect, namely the DNS root signature key management.
The other two foremost are the application usage of DNSSEC protocol functionality (see the discussion following this CircleID post) and the operational front, or the extent of deployment in the DNS infrastructure. The operational front includes the support by the DNS root nameservers, but my focus on signature key management leaves this issue aside.
Fundamentally, cryptographic techniques merely shift information controls into fewer hands. In the case of DNSSEC signatures on a domain name, this turns into fewer hands allowed to authorize DNS data publication. The DNS root is the implicit (grand-)parent of every domain. The fewer hands for the root are amongst those who are involved in DNS root zone management irrespective of DNSSEC signatures (there was a deliberate decision to preserve the prior arrangements with the introduction of DNSSEC). Accordingly, I would have nothing to report: the DNS root should be signed soon, otherwise it's business as usual for DNS root zone management. In fact, this is a fairly encompassing summary unless you want to delve into the subtleties of DNS root signature key management.
This comment is limited to the now current issues. We may suspect that now is the peak of DNS root signature project activities; thus it would be counterproductive to challenge design decisions, e.g. about the root signature key process flows. When such discussions were timely, the US government arranged the discussion forums such that its educated influence would prevail (after all, not only the US government has its historic role in Internet governance, it also has the NIST expertise in IT security techniques). But I doubt that any serious alternative could have emerged from more open discussion fora: a comprehensive solution to the conceptually simple task of officially signing the DNS root zone file is just too demanding.
The Pervasiveness of US Government Influence
It is nonetheless useful to summarize the nature and pervasiveness of US government influence on the DNS root signature. Here are the highlights.
NTIA-in-the-loop. The US government keeps his historic role in authorizing the changes to the DNS root zone file. This includes DNSSEC signature records.
Cryptographic keys handled by ICANN and VeriSign. This combines the abovementioned decision to keep the same DNS root zone management once the root is signed, plus a choice by the US government to let its partners provide the dayly operational support. ICANN governance is well debated here and there. The VeriSign involvement may be useful to the US government as an additional control mechanism, just in case.
ICANN inherits the KSK can of worms. For the purpose of DNS root signature key management, the KSK (Key Signing Key and more specifically its private portion) is the single data element by which the fewer hands ultimately control the DNSSEC signatures. The can of worm qualification comes from misconceptions about the real capability offered by the KSK private key (in practice, litte more than an "opportunity" to trigger highly visible DNS operational incidents), plus the almost complete lack of applied cryptography scientific contributions about this very specific key management facet. VeriSign could have inherited the KSK management duty (in exchange of the ZSK which is relatively straightforward), so their expertise in X.509 certificate signature technology would have applied. Presumably, the US government was motivated by the ICANN dedication to transparency (which is genuine in the case of IANA operations, of which the KSK management is part). In contrast, VeriSign typically operates behind closed doors and with every conceivable excuses codified in "certification practice statements."
Directed technological choices. The US government mandated ICANN and VeriSign to use USG approved digital signature technologies in such a way that a single source is available for the crtical component known as an HSM (Hardware Security Module). In the same spirit of US government crypto culture influence, there are recurrent indications that elliptic curve cryptography signatures are preferred to the de-facto standard RSA, but that is not a current issue for the DNS root.
Overall, I see nothing wrong in any of these points: to the contrary, they allow the DNS root signature project to proceed with digital signature technology elements that are well known and widely accepted, with the exception of KSK private key processes that I am about to address. In some detailed aspects of the resulting DNSSEC root deployment plans, I could express reservations, but these would be counterproductive nowadays.
Trusted Community Representatives
The ICANN solution for KSK private key management embeds the novel notion of TCR for Trusted Community Representatives. Details set aside, the TCR roles (there are two of them according to the omitted details) are intended to allow recognized members of the DNS technical community to participate in the KSK private key processes. This should improve confidence and acceptance in the DNSSEC security mechanism among the wider Internet community.
If everything goes as intended, TCR volunteering will enhance global confidence that the "few hands" that control the DNS root signatures are clean. As I write this however, we miss reports about the level of participation in the candidature period (closed on last April 23), and the perceived effectiveness and relevance of TCR roles among would-be volunteers.
The current questions are thus a) is everything going as intended, and b) does it matter. The questions are naturally addressed respectively to ICANN and to the readers of this comment. My personal slant on this: if ICANN was too optimistic in the level of TCR volunteering, it would be acceptable to rely on some plan B, e.g. where insiders and/or non-members of the DNS technical community could participate, along with lesser emphasis on geographical distribution of participants.
This specific issue of TCR roles criticalness (as perceived by those who could volunteer and those who may not but could feel free to complain) is kind of the tip of the tip of the iceberg in a cryptographic key management hierarchy overlaid on the domain name hierarchy. The tip of the iceberg gives sufficient warning of danger, we may ignore the tip of the tip! Also, it is an orphaned issue, because nobody produced a serious DNSSEC risk analysis from which TCR roles criticalness could be assessed. My attempt at a DNSSEC risk analysis (for the related purpose of validating procedures for an alternate source of unofficially signed official DNS root data) is nonetheless clear: you might fear subverted DNS root signatures only if you both a) distrust the US government and its partners, and b) see your Internet traffic as a specific target in isolation from the global Internet. In a nutshell and after a detailed analysis, the TCR role definition brought forward by ICANN is a nice attempt at formal transparency, but far from essential.
The concluding good news item is that a high level US government civil servant stated very recently: In the coming months, we expect to make DNSSEC at the root a reality by authorizing ICANN to publish the root trust anchor and VeriSign to distribute a validatable signed root zone. That statement is precise and unambiguous: there would be no show-stopper in the DNS root signature project monitoring by US government NTIA and NIST agencies.
Then what is the conclusion for you and I?
Maybe the above account of the US government influence is accurate, and we should determine that it is acceptable even in the long run. Otherwise please consider turning around your objections into something constructive and show support for the Intaglio NIC project blueprint.
Finally, just wait and see for the following few months, or if you feel so send an e-mail to IANA (iana at iana dot org) in support of "any reasonable plan B for TCR roles volunteering" in case they face difficulties with the KSK private key ceremonies.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services
.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»