[dnssec-deployment] DNSSEC plenary discussion paper - trust anchors, last mile, etc.

[Patrik Fältström]

I must say I do not like the paper either, but maybe that is too  
strong wording. The content is there. I think one can argue with the  
wordings (many other have already done so), but that is not the  
problem I have (at this point in time). I think the problem is that  
this document is not at all about "problems related to DNSSEC  
deployment", but instead "how to run TARs".

A document that talk about problems related to deployment of DNSSEC  
should talk about multiple TARs, but I do *NOT* see that as a main  
problem related to DNSSEC deployment. Documents that are written this  
way are read by non-DNSSEC aware people as if TLDs and the root zone  
have to be signed, and creates a big need for additional documents  
that explain why the root, TLDs etc have to be signed. "They do not  
have to, as we have TARs, and see this document how people work in  
getting TARs deployed!" Yes, I have got that in my face several times  
already. Not because of THIS document, but other documents.

My preferred outline of a document should instead start by going  
through the real issues that exists EVEN THOUGH every TLD and root  
zone is signed. As you know, we have DNSSEC signed .SE zone, and I  
have personally been running the technical part of a small registrar  
that accept DNSSEC data, I also host DNSSEC signed zones (a few  
hundred of them) with every problem that involve. There are TONS of  
problems already in this scenario when things are deployed, and I  
think documents should concentrate on THAT.

TARs is only a small detail, and I claim the "problems" we have with  
TARs is only a small details compared with the real problems related  
to DNSSEC deployment.

Let me list some of them that pop up from my head immediately, in no  
specific order:

1. When a zone is to start being signed, "DNSSEC" has to be "turned  
on" in the registry. This involves most certainly communication  
directly or indirectly between the DNS administrator (not that I am  
not saying domain holder) and the registry, and very very few TLDs in  
the world have a secure path between the DNS administrator and  
themselves. "Turning on DNSSEC" is in Sweden one operation that is  
done by the registrar (on request from one of the adminc, techc etc),  
and publication of the DS (transfer of "key material") a different  
operation.

2. When a zone is to stop using DNSSEC, it is not really known how  
that is to be handled. In Sweden, it is done by removing all DS data  
from parent zone -- I hope, I have not tried (and I do not know  
whether anyone else have tried).

3. When publishing DS data, and changing it, there are discussions in  
Sweden what a proper TTL is on the DS and signature of the DS. Sure,  
one can always have multiple KSKs, but do normal zones have that? I  
must admit I do not in my deployment strategies. Do we know how to  
manage the DS records in the parent zone so that it is optimal in  
relation to key management in child zones? I claim we do not.

4. When passing the DS data to the prent zone, the data is most of the  
time passed from the DNS operator of the zone to the registry (compare  
with (1) above). In Sweden, the process is like this: new keys are  
published in the child zone, and a registered admin have to log into a  
website of the registry and manually "click" a button to have the  
parent fetch the keys. The only automated process is one that a  
registrar can do as part of the registry/registrar communication, and  
because of this, in reality only DNS hosting companies that also are  
registrars can run large scale DNSSEC hosting. This can/will have a  
big impact on DNSSEC management and the registry/registrar market  
economy (the balance between power between the parties involved  
{registry,registrar,dns operator,registrant}). Will adoption of DNSSEC  
make it MORE important that the registry have communication with the  
DNS operator than the registrar? Do we need registrars in the future?  
Do we need contracts between all DNS operators and registries? Many  
people think we need contracts between dns operators and registries as  
well, but the question is what operations the dns operator should be  
able to do so that they do not take over from the registrar.

5. Transfer of a domain name is a problem. Just look at (4) above, and  
the role the registrar has. What should happen explicitly and  
implicitly at the time of a registrar transfer, or a change in domain  
name holder? We must definitely have a global agreement on this, and  
not something that is up to the registrar. Maybe we can have different  
views between registries in the world, but I doubt. Maybe... Today,  
not even registrars have clear documentation on what the policy is.

6. Even if the above is sort of sorted out (as in Sweden) people do  
not ask for DNSSEC. Why? I do not know. To start with, it was clearly  
the price. It does not matter what people not living in Sweden say but  
charging N for delegation and then charge extra for DNSSEC is  
problematic. Same problem as with IPv6. There is NO business case for  
DNSSEC. It is that simple. I have in my DNS hosting made the decision  
to have DNSSEC signed zones for all zones. That is the only way for me  
to run DNS for a low cost. Too much problem if some customers have  
DNSSEC and some do not. Finding errors is too problematic if "do they  
run DNSSEC" is one of the parameters. So, if the registrant do not ask  
for DNSSEC, how do we convince the DNS hosting companies to run  
DNSSEC? What do they need? Key management systems that are automatic?  
Is the problem "only" 1-5 above which make them not happy investing  
yet? I hope so. But we clearly lack tools. I had to develop my own  
(which is so ugly I will not share them).

7. Verification, of course we need to have DNSSEC verification of  
stuff, or else there is no need for deploying DNSSEC. It seems large  
resolver operators in reality do not have much problems turning on  
DNSSEC verification because it does not take so much extra CPU, memory  
etc as some people claimed. So what is the problem? The issues below?  
I think/hope that easy.

8. Key rollover...this is of course a problem. When keys are rolled,  
keys that are hardcoded in the resolvers, how do the resolvers know?  
This is a major issue, and we just have to work harder on this. Of  
course, harder when having more than one key in the resolver config,  
but the problem still exists if there is only one.

9. If one want to be "a good resolver operators", one will for some  
time have multiple keys in the resolver config. How to know which  
ones? A problem similar to the black-, white-lists for email. Which  
ones are good and which ones are bad? Are all good? How do I know not  
a bad guy give me key material?

10. A lot of people still talk about "the need for indication in the  
_application_" whether the reason DNS lookup failed was because the  
record does not exist, and the signature did not validate. Is this  
needed? If it is needed, how to have it implemented, and what  
conclusions can be drawn?

11. The last mile, the communication between the local resolver and  
the trusted resolver that do the verification. How is that secured?  
Only by having the verifying resolver locally, or by having an IPSEC  
tunnel, or by use of TSIG and always the same trusted resolver? What  
implications are there in deployed DNS with each one of these models?


Note that I am not listing TARs anywhere among the problems, and that  
is intentional. TARs can help and be the solution to some of the  
problems. But it is important TARs are not part of the problem. TARs  
are part of the solution, to some problems, maybe, and that way one  
can view TARs as what they are -- I think.

Also note that many of the issues I list are discussed in the  
document. Some of them are discussed as part of the TAR discussion.  
Some of them are discussed elsewhere. I think it is wrong listing them  
under the section(s) about TARs as they are generic issues/problems we  
will have even without TARs (as I think we for various reasons can not  
call "the one and only root key a TAR").

     Patrik