[security] DNS-SEC the solution?

Dick Hardt dick at sxip.com
Fri Aug 8 20:05:16 UTC 2008


On 8-Aug-08, at 12:32 PM, Ben Laurie wrote:
> Well. The underlying issues are:
>
> a) The root must be signed. This means you are buried in ICANN mire.

Does the root need to be signed? Signing at the TLD works. Means you  
have to get keys for each TLD, but not it is only the TLDs that *want*  
to support DNS-SEC.

>
> b) For the large registrars the cost (operational and capital) of
> DNSSEC is significant. Millions. Lots of millions.

I can see the issue for .com etc. where the fees for the domain have  
at times become a loss leader for other services.

One could envision registrars wanting to move up the food chain and  
being able to charge for the extra value and with the ability to have  
new, special purpose TLDs, one could envision a market for multiple  
DNS-SEC enabled TLDs -- and not unlike the SSL cert market today --  
you need to get your root cert embedded in the distributed software  
somehow -- but you don't have the CRL issue of the current PKI.

>
> c) No-one's really figured out what you actually do when the
> verification fails - tell the user? Fail utterly?

I agree that there is now a new failure mode for existing uses of DNS  
that has challenges for existing software. For new use cases though,  
developers know it could fail and do what is appropriate. For use by  
OpenID, I would imagine that whatever system is relying on the  
verification, would fail and appropriately inform the user.

>
> d) If the user does DNSSEC then how do they configure root keys and  
> do rollover?

This sounds solvable, particularly if there are multiple, cooperating  
TLD operators.

>
>
> e) If the user instead relies on an upstream server, then:
>   1. are they any better off? the last mile becomes the target.
>   2. how do you report errors?

Clearly they would need a "secure" connection upstream.

(d) and (e) exist in PKI today.

>
>
> f) Most people don't care.

That is the big issue with pretty much all security products.

CRL checking was not enabled for many products because the perceived  
costs in user experience / performance were not outweighed by the  
perceived increase in security.

Having been a vendor of a number of security products, customers are  
motivated:

A) when told they have to do something to comply

B) when something bad happens to them or someone "near" them so they  
act of fear that it will happen to them

C) when they are doing something new, and are scared of what might  
happen

There is very little motivation for people to change something that  
seems to be working fine now.

OpenID is a "new" thing, and therefore could be a catalyst for  
deploying new security solutions.

-- Dick



More information about the security mailing list