In message <006f01cda651$faa63210$eff29630$@[email protected]>, "Daniel P iggott" writes: > 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?
Perfectly do able. You just pass them the TLSA record to be added to the zone or you pass them the CERT and tell them to generate the TLSA record for it. CERT to TLSA is a mechanical processs. The only thing addition is what type of TLSA you are going to generate and for that you have a choice of 1 of 4 values. This really is no different to passing them a A record for a server. > What if the host that controls the domain does not support dnssec currently? Ask them to fix their infrastucture or find another company to out source to. Nameserver have supported this for 1/2 a decade now. This is like IPv6. They just need to get off their butts and do it. > 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? As long as you have a seperate IP addresses (IPv4 and IPv6) for your virtual machine you just need to add the CERT to the server's config. This is no different on the server side to traditional CA derived CERTs. If the provider can install a CA derived CERT they can install a self generated CERT. > 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 This stuff isn't rocket science. It's the client side that need extensions to be able to validate. The server side is "same old same old". Mark > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
