[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