[0x0]

>> The trust anchor for .com is Verisign.

>Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records...

Verisign runs the "com." zone, so I guess they would have to admin any DNSSEC/DANE/TLSA stuff.

[kilburn]

They only have to admin the DNSSEC stuff (publish your domain name keys along with your nameservers, as you set them up through your regular domain provider).

The DANE part needs no further support than you being able to use DNSSEC for your domain's DNS. Obviously there is always some entity controling each TLD, and that entity can screw up your domain if it acts improperly.

[tptacek]

You're not following. DNSSEC is secured by a chain of keys leading to a root; the entity that controls the root controls the chain. If you use DNSSEC to authenticate your certificate, you're giving control over your certificate to whoever runs the roots.

[schoen]

That last property is what makes that entity a "trust anchor", and what DANE critics specifically don't like or want to get rid of.

[0x0]

So you will have to trust Verisign not publish a different, compromised, set of domain name keys along with your nameservers.

[vertex-four]

You have to trust them not to do that anyway right now, as they're a CA. You also have to trust any of the >100 other CAs that your system trusts.

[tptacek]

Nobody is suggesting that the naive X.509 scenario we had a year ago is secure. They are, however, skeptical of the idea that we should invest millions of dollars into an architectural change to the core of the Internet to land... right back where we are now.