On 02/06/2011 09:11 AM, Zack Weinberg wrote: > On 02/05/2011 02:55 PM, Eddy Nigg wrote: >> >> However probably the optimal approach will be CA issued certs in DNS >> that also make use of DNSSEC to validate the former (DV). Eventually I >> believe that this will emerge as the real improvement and most useful >> approach for software vendors and CAs alike - providing real value for >> what DV is supposed to do and by closing the entire circle. > > I'm going to ask you the same question I asked Nelson: In a > hypothetical world where DNSSEC+TLSA completely supersedes DV (but > people still use OV/EV for high-value sites) what do you see as having > been lost? I really doubt we will see that world. I expect the DNSSEC could take a significant portion of the DV market, but I doubt it will completely replace it, any more than I think DNSSEC+TLSA can be ignored. > Or, turning it around, what value do you see DV signatures from CAs > as providing over and above that provided by DNSSEC+TLSA? One primary place the DV has the advantage over DNSSEC is on large, rotating server farms. These farms don't need to keep track of each key on each of their servers. The certificate and key are always together on the server. For them, keeping the DNSSEC+TLSA keys up to date for all of their servers behind firewalls would be an administrative nightmare.
My primary worry of the this spec as is is that DNSSEC is trying to be the end-all-be-all authority. That's a recipe for disaster. Keeping all my server keys in sync with the DNSSEC record? And if I have OV/EV, I have to keep it in sync with the certificate I have. If the spec requires us to reject certificates that don't match DNSSEC key records, then conservative websites just won't use DNSSEC+TLSA (or they will, get out of sync, and browsers will ignore the requirement and do what the market requires). The requirement, from a security point of view, assumes that the DNSSEC infrastructure will be more trustworthy then CA's in you trust store. I think that is a value judgement, not a security judgement, and therefore has not place in a spec. > > zw bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
