On Mon, 22 Oct 2012, Rick Andrews wrote:
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.
How is replacing the TLSA record not equal to revocation, except within
the middle man delays?
- 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.
That seems more like a local policy to me. It has also been called
"Frequent Rollover Syndrome" by some.
- 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.
Systems now would "very likely" not generate insecure stuff. CA's have
been pretty good at issuing bad certificates. I find this argument
pretty weak. The market has shown a strong preference for the CA with
the least amount of checks, delivering a cert in seconds rather then
hours or days - not a mechanism to build up security.
- 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.
Yes, and you are right we are adding new risk points. But those are much
fewer (root, .com, registrar webgui, DNS hoster) then the plethora of
CA's. But still, DANE allows you to do both, so we can all be hapy.
Maintaining TLS certificates actually becomes _easier_, because people
don't have to frantically read the openssl man page to generate a new
certificate when the old one suddenly expired without anyone noticing
before the complains hit the help desk.
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.
If only CABF was open, I could actually try and reason with you to see
if you are right. Unfortunately, CABF recently comitted to remain
closed.
As for your "if we allow DANE w/o PKIX" comment, the DANE RFC does allow
it, and with good reason. Contrary to your claim, it will actually
_increase_ TLS security by being able to phase out self-signed cert
popups for those people who can't or don't want to pay the CA industry.
The payment system is frankly the main course of reduced TLS security,
and DANE fixes that nicely.
This does not stop you from your business model. You can remain issuing
EV certs, browsers can provide additional colouring signifying the
additional checks done by CABF, and people can add TLSA records to pin
it to a single CA to not be affected by another CA's compromise.
Saying the masses can't have 'secure websites' because it would enable
the bad guys to have 'secure websites' is not a strong argument.
Following that, we get governments banning encryption altogether.
Paul
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
