In message <6F2A9C4EF7A35E87B09D37EF@xxxxxxxxxxxxxxxxxx>, John C Klensin writes : > > > --On Wednesday, August 06, 2014 07:15 +0200 Patrik Fältström > <paf@xxxxxxxxxx> wrote: > > > > > On 6 aug 2014, at 04:26, Dave Crocker <dhc@xxxxxxxxxxxx> 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@xxxxxxx