On Mon, October 22, 2012 2:54 pm, Rick Andrews 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.
Nor is there any effective provision in the CA model for key cryptoperiods. If a CA denies reissuance to a customer because they tried to reuse an existing key, the end user need simply go to another CA. Given that nearly all CAs are equal in trustworthiness from the client perspective, this is not in fact an active mitigation provided by CAs. Keysize and hashing requirements are already implemented in clients - Chromium, Safari, Mozilla, and Microsoft have moved to deprecate MD5 and < 1024 bit certificates. I imagine that these requirements will continue to roll forward - primarily gated by the limitations of the existing deployed infrastructure and the need to not break all of the sites with legitimately-issued WebPKI certificates. > > - 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. Agreed. This is an understandable benefit of having a third-party mediate key issuance. > > - 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) and to millions of individual domain owners (for > generating and maintaining their keys). 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. Out of curiosity, given that both DV and EV ultimately rely on the validity of the domain registration information, what is to prevent a malicious DNS zone from compromising or otherwise maliciously requesting a certificate? That is, as the zone operator for .com, is there any more or less risk with DNSSEC that I may lie about who owns victim.com? If I can lie about who owns victim.com, I can induce a WebPKI CA to issue a (domain validated) certificate for victim.com. The DNS zone operator remains in a privileged position in the PKIX world, since PKIX ultimately relies on the validity of the DNS registry as a key part of performing validation checks. Yes, EV improves these checks, but there is still an inherent reliance on "party X is authorized to request for victim.com" As far as being vulnerable to the millions of sites' key management practice - again, how is that different than the existing PKIX model? With the exception of EV Code Signing, no documents produced by the CA/B Forum require, for end-entity certificates, the use of an HSM or otherwise secure key management. I can appreciate the concern for /usability/ - which is, indeed, a clear and real issue with ANY form of key management. But the suggestion of audit being part of the concern, given that the vast majority of sites happily store the private key unencrypted on the web host machine, seems like a bit of a stretch. > 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. Has the work been to tighten up the poor PKI practices of end users, or the poor PKI practices of CAs? _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
