> -----Original Message----- > From: Ben Laurie [mailto:[email protected]] > Sent: Tuesday, October 23, 2012 2:14 AM > To: Rick Andrews > Cc: Paul Wouters; [email protected] > Subject: Re: [therightkey] TLSA Cert. Usage > > 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.
DV is no better at preventing attacks from those who can subvert DNS. The point I was trying to make is that with any CA-issued cert, a set of checks will be performed on the key and other cert contents that will not happen if the cert is self-signed. > > and to millions of individual domain owners (for generating and > maintaining their keys). > > Domain owners already generate their keys, don't they? Yes, but with DANE w/o PKIX I have to trust that the domain owners with self-signed certs did everything right when generating their keys and certs, because no one is checking them. > > 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. True, and groups like OTA and CABF are trying to improve standards. I'm advocating improving the existing system rather than throwing it out and bringing in a new one that is not arguably less trustworthy. This is a bit of a tangent, but IMO the browser vendors have not helped much to improve the status quo. They created a trust system in which all CAs are trusted equally, and they are reluctant to remove any CA's trusted roots from their browser. I'd like to brainstorm how those issues can be addressed. > > 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. I agree fully that CT would allow lots of actors to monitor everything. But what if you build it and they don't come? -Rick _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
