John, 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. An SSL cert is a heck of a lot cheaper than a course on PKI. 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. DNSSEC deployment is far, far beyond the capabilities of the average Internet user. It is also far beyond the capabilities of the typical ISP. 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. Attacking the service industry that supports crypto does nothing to advance the cause of making crypto ubiquitous, quite the reverse. 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. >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. On Tue, Oct 9, 2012 at 2:39 AM, John Gilmore <[email protected]> wrote: > > At least 3 host names in the list of DANE test sites do not use DNSSEC. > > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ > > Then it's a good thing that we're testing that case, isn't it? :-) > DANE implementations should refuse to connect to those test sites, > which don't have DNSSEC signatures all the way back to the root key. > (The fact that DANE should fail with them should be mentioned in that > page tho.) > > > >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same > as > > >> 3. The difference is that if my certificate is signed by a CA I use 1, > > > > Well, my point is that they transfer exactly the same data. 0 transfers > > an end-entity certificate and so does 2. They differ, as you say, on > > what the receiving party does on that data. Why bother? How would a > > server operator ever know what the receiving party will do on the data? > > This is a protocol. It defines what both parties do -- not just > one party. Two parties interoperate in a protocol when BOTH implement > it correctly. > > The whole reason for the "duplication" in certificate usages is to > protect the business models of the CA operators. For 98% of web > sites, there is no real need for usage 0 or 1 or 2. Just use 3 and > the DNS will let your TLS application know that it can trust the > public key that the TLS server provides. Indeed, the CA companies > tried to kill off usage 3 -- and succeeded to the extent that you have > to read between the lines of a complicated RFC to figure out that you > don't need the CAs anymore. > > You can continue to pay a CA for your TLS server's cert, so that > clients who don't implement DANE can still access your server with the > same security that you and they had last year. But any client that > does implement DANE will just use your "usage 3" TLSA record, will > ignore the CAs, and will have higher security. > > But the CA companies can say, "Use DANE with our certificates" and > still sucker a bunch of businesses into paying them $$$$$ that they > don't need to pay, for security that isn't really there. And indeed > DANE does provide a way to improve the security of the CA model, by > limiting the number of CAs who can betray you, from hundreds down to > one. Of course, if you use DANE with usage model 3, NONE of the CAs > can betray you to a DANE client -- but they won't tell you that. > > By the way, you're confused about which cert usage numbers do what. > The TLS server always sends the client a chain of certs, containing at > least one cert. The client only has to pay attention to the first of > those, which is the "end-entity" cert for this TLS server. The rest > are "hints" about how the client might determine whether to trust that > "end-entity" (TLS server's) cert. Unfortunately the process that the > client goes through is undocumented and unstandardized and will remain > so for business reasons (different clients do it differently and none > of them wants to be declared non-compliant). They all rely on "trust > anchors" which are keys that are inherently trusted by that particular > client, usually because those keys were installed automatically along > with its OS or along with its browser. DANE provides three ways to > *modify* that undocumented process, and one way to bypass it > completely: > > 0 = I'm telling you one of the PKIX CA certs (or its key) > 1 = I'm telling you the PKIX end-endity cert (or its key) > 2 = I'm giving you a PKIX cert that provides a new trust anchor (or > a key of one that the server sent in its chain) > 3 = I'm telling you the non-PKIX key or cert of this TLS server. > > 3 is the complete bypass of the PKIX hierarchy of certs. 0,1,2 all > use the PKIX certs and require that the TLS connection fail if the > undocumented PKIX client processing says "insecure". They also require > that the TLS connection fail if PKIX says "secure" but its ultimate > trust-chain doesn't match any cert or key that DANE provides. (That's > DANE protecting you from corrupt CAs.) > > Normally, usage 2 does NOT use an end-entity cert. There's a way to > bastardize usage 2 by providing the end-entity cert or key as the > "trust anchor", but that's just a slow way to do usage 3, so there's > no point to it. What it's really for is to provide a CA "trust > anchor" certificate that you don't expect clients to already trust. > For example, IBM might run its own CA for all its internal machines, > and could provide this CA's trust anchor cert in its internal DNS with > DANE usage 2, rather than having to reconfigure every machine in its > network to add a trust anchor manually. > > John Gilmore > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
