In message <6F2A9C4EF7A35E87B09D37EF(_at_)JcK-HP8200(_dot_)jck(_dot_)com>, John
C Klensin writes
:
--On Wednesday, August 06, 2014 07:15 +0200 Patrik Fältström
<paf(_at_)frobbit(_dot_)se> wrote:
On 6 aug 2014, at 04:26, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
Use DANE without DNSSec, and calling it opportunistic
probably makes sense. Using it with DNSSec and it doesn't.
The devil is in the details. I think we disagree on the
meaning of the word "opportunistic", and the evaluation of
whether you are lucky enough.
Personally, I think that as fragile the current CA system is,
I think DANE without DNSSEC is more stable and better than the
current CA system. And better than self-signed-certs that one
"just accept" (which happens quite a lot).
Conversely (and without agreeing or disagreeing with either of
you), the discussion suggests noting, again, the very limited
nature of what DNSSEC actually protects.
DNSSEC is designed to protect the data from when it is entered to
when it is retrieved by the application. It is the applications
fault if it is not validating answers it receives.
DNSSEC works with stub resolvers. The application just has to
request the DNSSEC records be returned. There are a number of
validating stub resolver libraries. Libdns has been able to perform
in this role for 15 years now. named calls libdns to do its
validation.
Validating in the recursive server is a *necessary* step in getting
a working DNSSEC path to the application but it was *never* intended
to be the last place that validation was performed. It provides
protection against attacks on the traffic between the recursive
server and the authoratative server. It doesn't protect between
the recursive server and the application.
If, and only if, you have a trusted path between the recursive
resolver and the stub resolver, and you know the validation policy
of the resolver and agree with it can you trust the AD bit. Unless
you are running a validating recursive server on the same machine
as the application you will most probably not meet the required
level to trust AD. If you use a ISP's nameserver you should not
trust AD.
I believe but have not verified that most DANE implementations
actually validate answers in the application. This is where we
expected the ultimate validation to be done when we started developing
DNSSEC. In application includes within a library the application
calls.
It is ultimately an
integrity test within the DNS hierarchy. If the resolver
associated with the user's application is not DNSSEC-validating
and within that user's trust boundary, then relying on DNSSEC
for protection is only as good as the intermediate trust
situation, e.g., whether the client user trusts the testing and
validity assertions of her ISPs forwarding DNS system. There
is reason to not do that. First, it may have changed but at
least up to some years ago, those ISP "DNS servers" were much
more often compromised than, e.g., authoritative servers for
root or TLD domains. Second, some ISPs have discovered that
that they have economic or political incentives to alter DNS
queries or responses. Enough have done so under various
circumstances to discourage uncritical trust.
The other end is equally bad. DNSSEC protects the integrity of
data already stored in the DNS. But, if the proverbial Bad Guy
can compromise a domain name registrar and register a name that
is misleading or otherwise problematic, certificates tied to
that name may not be very useful, especially as assertions of
good and upright behavior associated with, e.g., mail traffic.
Whether DANE-type certificates that depend on DNSSEC and
registrar integrity are more of less trustworthy than PKI-type
certificates that depend on certificate chains,
low-assertion-quality certificates, and CA integrity is an
interesting question... but one that might easily be resolved by
a race to the bottom.
While there is a threat with registries and registrars I believe
you are overstating the threat. Being able to register a new name
is NOT a threat. What is a threat is compromising registrant and
registrar accounts, unauthorised transfers, a registry publishing
unauthorised delegetion data, and the private keys of the registry
being leaked / used in unintended ways. Note apart from private
keys these are threats that registries and registrars have to deal
with in plain DNS and should already be taking steps to address.
john
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org