Just like users can be fooled into trusting fraudulent SSL-enabled Web sites, they could be fooled into trusting fraudulent hosts. User interaction is just as important as the technical deployment specifications, yet little work is being done on that front.
If DNSSEC will actually be useful for users, a few things need to occur:
1. Browser vendor should agree on a consistent method to display the status of DNSSEC to the user in an unambiguous and clear manner. Even something as a text representation of "Authenticated Host" or something like that.
2. Web sites that are known to contain sensitive information or activity like financial institutions, online retailers, health care providers, and other entities that should have a higher standard of trust, should be required -- through regulation or best practice -- to use DNSSEC. If bank A uses DNSSEC and you get a DNS response that is not signed, the user should know that is a potential problem. But a user shouldn't have to keep track of which banks use DNSSEC and which don't.
Users can make the right decisions if they are given the right information. That is just as difficult as figuring out how to generate the response in the first place.
Full article: Mike Fratto, "DNSSEC: Forgetting The User, Again.", Retrived on Feb 24, 2009 from informationweek.com/blog/main/archives/2009/02/dnssec_forgetti.html
Posts
I think there's slightly more to this. Telling the user something about DNSSEC is a good idea. Wes Hardaker is the guy you want to talk to about this. However, getting keys that can be verified in any way is an important (and often overlooked) part of this equation. What can you tell a user if the key that came from a DNSSEC response verifies a signature? Just that IF that key is valid, the signature means something. I think I take exception to your statement, "... yet little work is being done on that front..." Have you looked at _our_ blog: http://blog.secspider.cs.ucla.edu/ ?
ReplyDelete