Would a future with a ubiquitous DNSSEC deployment eliminate the market
for commercial CAs?
Would functioning DNSSEC + self signed certs be more secure/trustworthy
than our current system of trusted CAs chosen by OS/browser developers?
See Dan Kaminski's presentation at this years BlackHat & Defcon
for a proposal, and the prototype "glue" that provides a proof of
concept. http://www.recursion.com/talks.html (I seem to recall
the X.509/CA part starts about 3/4 of the way through the deck).
That said, Dan does not suggest that everything a CA does
is obsolete, there will still be a market for making sure that
BankOfAmerica.com really is the bank you want to do
business with (branding).
Would a future with a ubiquitous DNSSEC deployment eliminate the market
for commercial CAs?
No, but it might eliminate the cheapest certs that people might use. I'd like my personal server to have a self-signed cert with it's fingerprint handled via DNSSEC, because I don't want to pay a CA.
Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers?
No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together.
For DV (domain validation) certificates one can definitely make that claim, but for EV (extended validation) I would see certificate validation in DNSSEC as a complement to EV.
DNSSEC and EV together looks like a promising combination.
Disclaimer: I am co-author of http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-00 (work in progress, see http://www.ietf.org/mailman/listinfo/keyassure for more information).
jakob
Is a DNSSEC capable stub resolver not in the cards?
> No, because DNSSEC isn't secured all the way from the DNS server to the
> application, only to the resolver. Both systems have problems, I'd
> imagine the best security is when they work together.
>Is a DNSSEC capable stub resolver not in the cards?
The best option today is to run a full-service resolver on the host;
which is a tad heavy for most desktops, not to speak about the cache
misses that would cause root server system load. The latter of course
can be avoided by setting forwarders.
OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND
suite. Calling it from applications does however mean using new API
calls; since the traditional resolver API is oblivious to DNSSEC.
yes it is. unbound was originally designed for that very niche.
--bill
Subject: Re: DNSSEC and SSL Date: Sun, Aug 22, 2010 at 09:11:43AM -0400 Quoting ML (ml@kenweb.org):
> > No, because DNSSEC isn't secured all the way from the DNS server to the
> > application, only to the resolver. Both systems have problems, I'd
> > imagine the best security is when they work together.
> >
>
> Is a DNSSEC capable stub resolver not in the cards?The best option today is to run a full-service resolver on the host;
which is a tad heavy for most desktops, not to speak about the cache
misses that would cause root server system load. The latter of course
can be avoided by setting forwarders.
that assertion is unverified. i suspect that cache misses
would not overload the system as it currently stands. (modulo
a ramp up of DNSSEC capable stubs/full service IMRs).
OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND
suite. Calling it from applications does however mean using new API
calls; since the traditional resolver API is oblivious to DNSSEC.
perhaps a review of lwresd/unbound would be worth a
gander.
--bill
The DNSSEC-Tools project has instrumented a large number of applications
with an in-application validating resolver. Including OpenSSH (with a
new auto-accept-keys option!), sendmail, postfix, libspf, thunderbird,
lftp, wget, ncftp, ...
Unbound is a full service resolver not a stub resolver.
Tony.
lwresd is in fact a full service resolver, though it is designed for
forward-only usage. Although its man page says it is "stripped-down", it
is in fact just the normal named binary running in a mode with a simple
canned configuration that gets its forwarders from /etc/resolv.conf.
AIUI, lwresd was originally conceived to deal with the original IPv6 DNS
support (A6 records and binary labels). It would need quite a lot of
re-working in the lwres client library (and possibly also the lwres
protocol) to provide proper DNSSEC support.
Tony.
depending on configuration, unbound can be used as both a full service resolve and a stub.
jakob
PowerDNS resolver. Very fast, very light.
--Curtis
The fact hat Verisign kept the domain business and sold the CA
business to Symantec tells which business they think is stronger.
Rubens
The fact hat Verisign kept the domain business and sold the CA
> business to Symantec tells which business they think is stronger.
FWIW, I remember being at a tech company some of you have heard of
when the CEO announced we'd just sold one of the more profitable
non-core units to help fund core product devpt.
Someone in the audience pointed out it was probably our strongest
(non-core) unit, why not sell one of the weaker ones?
"We wouldn't get a lot of money for a weak unit now would we?" he
answered.
So, maybe yes, maybe no. But this reasoning alone doesn't settle it.
For the purpose of DNSSEC support powerdns might not be the best choice. They are late to the game, and only added DNSSEC support reluctantly due to market pressure. There have been other good suggestions in this thread already, but as always evaluate all possible solutions for your particular use case(s).
Doug