[dnssec-deployment] Comments on the TAR paper

[Paul Wouters]

> Encouraging more "copies of data" is a step in the wrong direction. These 
> TARs, if really intended to be perpetual, are eventually going to be yet 
> another albatross around the neck of network operators. I'm not talking about 
> things lingering on after the expiration date, I mean the establishment of 
> more points of failure and potential sources of incoherent data.

But not encouraging anything will cause "rogue TAR's" to appear, similar to
how we had alternative root/tld operators for a while.

> This scheme violates a fundamental principle of DNSSEC.  Namely source 
> authentication.  In this instance, the TAR, which is not the owner/maintainer 
> of the private key, will scarf up the public key and include it in the TAR - 
> if I understand this correctly.  This breaks the chain of custody.

Yes, it is a "leap of faith" done by the TAR. Though the TAR could be
pro-actively told by the zone itself, instead of hunting and gathering
zones via one of the dnssec spiders.

> In addition - if the SEP are picked up "silently" - where's the 
> accountability?   How can you trace where an update came from?  If you are 
> social engineered, how do you know that that was the cause of bad data?

"leap of faith" is better then nothing?

> 3) Multiple TARs with Similar... (3.4.2)
>
> This violates a basic DNS principle - coherency.  I find it hard to accept 
> that a system whose core requires coherency would be secured by something 
> incoherent.  Coherency in DNS at the global scale is necessary for the sanity 
> of global operations.  If the security system allowed fragmentation of it's 
> data I can't imagine how global operations could be able to maintain 
> assurance that the global system is operating in a "healthy" manner.

The TAR's could have a one month grace period where they kick out childs when
its parent because fully DNSSEC capable. So no incoherent or stale data around
in the TAR/DLV/list.

> 4) TAR registration policy (4.1)
>
> There are already established practices for registering domain names 
> (including domain names in the ARPA domain, etc., etc.)  There's already a 
> budding establishment regarding the registration of name - involving whole 
> seller, resellers, policies regarding practices, dispute resolution - and 
> section 4.1 talks about securing the underlying domain name system with a 
> completely different power and accountability structure.  (I get really 
> concerned when I see the words "barrier to entry" appear in a technical 
> document.)

Tell that to the Registry and the Registrars. If they "did their job",
we could already by supplying DS records to them (regardless of whether
those would live only in non-operational DNSSEC, whois OPT-IN, shadow zones,
experimental zones or TAR's)

> I understand that there is a feeling that the SEPs will be the responsibility 
> of the DNS operator.  But the DNS operator may be an illegitimate 
> representative of the domain name user.

If your technical guy on the inside is not to trusted, you call in the lawyers,
not the IETF squad.

> A recent flap has occurred over web 
> hosters registering their customers' domain name in the name of the hoster 
> and not the customer. Effectively this locks the customer into the hoster as 
> they customer can't transfer the name away.  This is the kind of issue 
> burning at the domain name business level these days - a mess I suspect TAR 
> establishment wouldn't want to get into.

Exactly. "whoever can add DS records to the zone is our contact". It's the
model NLnetlabs used with the .nl.nl SECREG, and it is what ISC's DLV Registry
model is. You can't start secoond guessing.

> I don't think the TAR can assume that the relationship between the domain 
> name user (customer) and operator is always amicable.

They can not otherwise assume, without being drawn into the conflict.

> 5) Organizational Considerations for Global TARs (5)
>
> "...The management and governance for the TAR must be internationally 
> acceptable." Why?

Becuse otherwise you don't have a global tar, but many regional tars with
different procedures to get in/out/updated.

> But I think in general that operating a TAR is going to take (more) work, 
> like anything else.  It won't be easy - "easy" methods to achieve security 
> rarely pay off - a "worth it" TAR is going to cost. What needs to be 
> established is that the cost of the TAR is going to be less than the benefit 
> to the relying parties.  Not only the cost of the TAR, but DNSSEC too.

See RBL's as something you get when you wait too long fixing a protocol (SMTP).
People want to use DNSSEC. I am using it. I am keeping hardcoded lists now.
At what point will I make my list available? And what point will my list become
the defacto-standard? We'll get a TAR one way or the other, but now we still
have a chance to set it up as right as can be in the current circumstances.

> It's not a matter whether TARs are needed - because without DNSSEC they 
> certainly are not.  It's a matter of cost.

They are needed, as long as the root and some big important TLD's are not
signed.

Paul