[dns-wg] What about the last mile, was: getting DNSSEC deployed

Yuri,

On Feb 16, 2007, at 2:37 PM, Yuri Demchenko wrote:
>> The question is how do they get the information that the data has  
>> been signed and the signatures validated.  Since with this attack  
>> they'd be going through a compromised server, they lose.  The only  
>> way out of that hole is if you run a local validating caching  
>> server and have appropriate (out-of-band validated) trust anchors  
>> configured and if you're running a local caching server, you're  
>> already not susceptible to the attack.
> I was thinking similar like home routers could have default  
> configuration to use DNSSEC responses, and maybe in the future only  
> DNSSEC.

Wouldn't this mean the nasty javascript merely updates the trust  
anchors to point to the bad guy's DNS server?  That is, if the home  
user doesn't configure the password and the trust anchors are  
configurable on the router, the bad guys win.

As was mentioned previously, this really isn't a DNS attack.  It is a  
"exploitation of a default password" attack, so DNSSEC doesn't help.

> As about trust anchors, in other security applications we looking  
> now closely at the TPM (Trusted Platform Module)/TCG technology  
> that provides hardware bound and hardware protected trust anchors.

This might work if it requires no end user interaction.

Rgds,
-drc