Just stepping back with a commercial third party hat on, can I add a few questions to this debate. If my understanding of DANE is wrong please let me know. I am talking here from the SME perspective. What if a business never handles it's dns but leaves it it's third party IT supplier? What if the host that controls the domain does not support dnssec currently? What if websites are sitting on shared virtual boxes and a reseller cannot make revenue from ssl certificates currently, why would they pursue dane from a commercial perspective? From an technical and security viewpoint I am completely sold on DANE but i see the current real world commercial and technical reality stopping deployment. Daniel
On Tue, 9 Oct 2012, Phillip Hallam-Baker wrote: > Your model for why people buy certs is completely wrong. > > The biggest cost in providing SSL certs is training the customer how to use and deploy them. I could not have summarized the failure of the CA industry better. If they had made $5 certs for everyone, we would have never seen the explosion in people using unvalidatable self-signed certificates. DANE is indeed a method where obtaining the validation is totally free, and it does not raise the bar for any non-enterprise that cannot afford a training budget. > An SSL cert is a heck of a lot cheaper than a course on PKI. The fact that one would need a course on PKI to secure one's webserver is a pretty bad failure of the security industry. We're paying the price now (and offloading that mostly to the browser vendors to fixup in gui elements) > The typical cost of training is $800 per person per day. How many days > does it take to know enough crypto for it to be more good than harm? Probably more than one. I would cost me $800 to go on a locksmith course for one day, yet I can easilly buy a lock or cylinder and install it myself. All one needs is knowledge of a generic tool such as a screw driver. Another example would be getting my drivers license, which was far cheaper then the price of my car. > DNSSEC deployment is far, far beyond the capabilities of the average Internet user. Funny, because these days signing your zone takes 4 commands you don't have to understand, and one more website visit to get your DS published. (Willing to give a 5 minute / 2 slide training at ICANN Toronto for less then $800) > We both have more than twenty years experience using this stuff and > neither of us is signing our emails, that should say something about the technology. no it says something about the value of signed emails. A few months ago I had to use SMIME for the first time ever. With thunderbird this took me about an hour (most time wasted on a website's interface for validating my generated cert). It also took one person to spend a little more time, and writing up a simple step by step manual. It did not take a full day course (nor knowledge of crypto - anything more then "red wax dot means your software signed the email" > Those DNS registrars that you hope are going to provide free crypto to > the masses are what CAs call their sales channel. Selling DNS names is > not a profitable business, most are sold at a loss in order to acquire customers that the registrar then monetizes though sales of added value services, in particular SSL certificates. If only they had started to give away free SSL certs 10 years ago, and perhaps by now port 443 would be the default instead of port 80. Forgive me for not having much sympathy for the CAs economic struggles. > From a security point of view, I think the whole approach taken in > DANE is wrong. It regards security policy statement as commands from the server to the client rather than as evidence that a client MAY chose to evaluate in making a security decision. > > No client is going to interpret the DANE MUSTs as mandates no matter > how hard people stamp their feet. The client providers refuse to deploy software that hardfails on OCSP status requests despite a considerably cleaner path to the client than is available in the DNS world. That could be said for any MUST in any Security Considerations RFC section. We set out to write what's best. If local policy dictates shooting yourself in the foot, we can at best help you not pull the trigger again. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
