On 22 October 2012 22:54, Rick Andrews <[email protected]> wrote: >> On Mon, 22 Oct 2012, Ben Laurie wrote: >> >> > CAs have been arguing in other venues that using TLSA to validate in >> > the browser is inferior to using CAs because CAs are prepared to >> > revoke certificates that are used for bad things, whereas DNS >> > registrars/ICANN are not. >> >> Of course, the registrant/DNS hoster itself _can_ and _should_ remove >> the TLSA record from DNS. Either when it used TLSA for pinning and the >> CA got compromised, or when the DNS provider itself got compromised. > > I'm one of the CAs that have been arguing in other venues that using TLSA w/o > PKIX validation is inferior to using CAs (w/ PKIX validation). Having an > established mechanism for revocation is just one of the reasons I believe > this. There are other reasons: > > - CA-issued certs will conform to CABF Baseline Requirements (minimum > key size, strong signing and hashing algorithm, acceptable validity period, > proper extensions). Most people would agree that an SSL cert shouldn't be > used for more than a few years, but there's no provision in DANE for > preventing long-term use of a single key. > > - CA-issued certs would be very likely to have undergone automated > checks for weak keys, weak exponents, not on Debian weak key list, not on > internal phish lists, etc.) But with DANE w/o PKIX, it's almost certain that > no checking was performed for weak keys. The person who generated the key > probably won't, and the DNS operator probably won't either, because they're > not required to. > > - If you move away from the CA model to a DNSSEC-based DANE w/o PKI, > you're shifting your trust to the operators of the various DNS zones and > domains (for DNSSEC PKI)
How is this different from DV certs? In some ways DV is worse, surely, since an attacker only has to own my domain temporarily and locally (to the CA) to get a DV cert issued. > and to millions of individual domain owners (for generating and maintaining > their keys). Domain owners already generate their keys, don't they? > None of those entities are subject to audit like the CAs are, and it's > reasonable to assume that without standards we'll have good ones and bad > ones. That makes the end user less safe, in my opinion. We appear to have bad CAs despite standards. > I actually like DANE. I think that it's a great addition to PKIX validation, > but not a substitute for it. If we allow sites to use DANE w/o PKIX, I > believe we're opening the door to poor PKI practices (which arguably have > been tightened up over the past few years by CABF). We're also allowing > attackers/phishers to create fraudulent web sites with SSL certs that appear > to be as trusted as legitimate sites. > >> > This is, of course, why Certificate Transparency exists, so everyone >> > can see what's going on. Neither TLSA nor CAs are adequate, IMO. > > I presume that CT will allow an auditor to see the actual cert that was > issued, Something very like the cert, anyway - where the SCT is issued from a pre-certificate, then that's what the log records, not the actual certificate. > so an auditor could take over some of the functions that a CA currently > performs (checking for key size, weak exponent, Debian, key lifetime, etc.). > But CT doesn't require anyone to do that, nor does it impose any requirements > on the auditor. CT _could_ impose requirements. I suspect people will monitor these things anyway, though. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
