On 2/10/11 8:09 PM, Eddy Nigg wrote:
There are additional steps CAs can/should/do besides checking domain
control - even in the DV settings.
Ok, so the theory here is that some DV CAs do some stuff above and
beyond baseline domain validation. We don't really know who is doing
how much of this, and a proactive attacker can target the least diligent
CA (or SubCA or RA). Nevertheless, the theory is that the incremental
value of these ad hoc activities outweigh the undeniable disadvantages
of the CA-without-DANE model (such as non-exclusion and lack of
delegation). All of this with the understanding that Mozilla doesn't
make any assertions to end users about anything w/r/t DV certs other
than domain validation. These reasons alone seem sufficient to call
this line of reasoning into serious question, but let's take a look at
your specific points.
Those range from basic sanity checks
Can you give an example? Would these checks be necessary under DANE or
are they specific to the CA third-party-domain-validator model?
checks on weak/small keys, weak hashes
With DANE, such checks are part of the spec and the client
implementation. As we have seen repeatedly on m.d.s.p., relying on CAs
to enforce checks consistently is far less effective than implementing
hard client checks.
domains with obvious problems
Don't know what this means.
re-validation
Unnecessary with DANE.
and other flagging mechanisms before issuance, phishing
detection and so forth.
>
> It continues with the ability to revoke certificates upon
> detection/reporting of misuse or other issues - it's a very strong point
> why a CA is beneficial.
I've made clear that I'm not a fan of such nannyism. To the extent that
it has to be done, the registries/registrars are simply a more direct
path. In many cases they already have revocation-for-bad-behavior
policies in place. We can both point to examples in the CA *and* DNS
spaces where domains we think are participating in bad behavior are
unrevoked, so I'm not sure how to measure the empirical effectiveness of
either approach. I do know that CNNIC recently undertook such extensive
measures in the name of shutting down phishing/spamming/malware that
they reduced the total number of .cn domains by millions (up to that
point it had been growing by millions a year). Of course, they also do
straight-up censorship by revoking .cn domain names... but in the US we
have begun to see questionable domain name seizures too.
With DANE, "revocation" of keys by the owner of the domain (vs. the
reigstry/registrar or a higher power) is straightforward and within
their control via normal DNS TTL and record removal mechanisms.
Additionally, DV may protect against a shortcoming of DNS that is
happening now and possible wrongful issuance of a DV certificate may be
detected due to shortcoming of DNS. Those are just the very obvious
points I mentioned before. Keys-in-DNSSEC can't provide that without the
involvement of a third party like a CA.
I can't figure out what this means.
The only thing that Mozilla requires of DV CA's is that they validate
domain ownership.
Well no, Mozilla requires a bunch of other things CAs must provide and
do, including OCSP and CRLs, ability to report misuse, revocation
requirements, sound PKI implementations (through WebTrust, ETSI), an
audit regime, its own policies and reviews and and and...just look at
the new policy requirements and how to apply. And this is just the
beginning, more is to come from Mozilla and elsewhere.
- OCSP and CRLs are unnecessary with DANE
- Can you point me to the place in the Moz Cert Policy that requires a
contact for "misuse" or defines what that term would mean? Likewise,
where is the definition of what constitutes a specific activity
requiring revocation (vs a general revocation requirement based on a
violation of the CP/CPS/SA terms, which vary)?
- Audits and the like serve only to limit the *additional* risks that
the CA DV model poses *on top of* its blind reliance on DNS. While it
might be a good idea to work toward more rigorous requirements on
registries/registrars, the CA DV model *already* suffers from any
existing weaknesses they have.
So all of these items you mentioned really only pertain to domain
validation, and involve implicitly trusting DNS, as I originally stated.
Anti-phishing and other punishments for actions that the CA doesn't
approve of are irrelevant
Why should they be irrelevant? They are certainly beneficial and very
relevant indeed, otherwise why having them in first place. Subscriber
obligations are not just here for fun.
I think we covered this above. Everything below is opinion and
conjecture, so I'm less interested in discussing it.
I will however say that DNSSEC is available today for a large portion of
the internet (.com about to go live), and work on DANE is proceeding
very quickly and has working proofs-of-concept. As others here have
said, ignore (or dismiss) at your peril.
I'm knowing both sides very closely. Those of the relying parties
(including software vendors) and those of the CAs. I know the ins and
outs of running a CA with everything it entails. If you haven't been
there, you probably don't know enough yet.
But I'm also putting my money where my mouth is and I take some credit
for changes that occurred and are occurring in this industry. Being it
for providing an alternative (business model) to commonly known and
conventional CAs and being it for guiding and demonstrating better and
more responsible policies and practices and pushing for those to become
applied evenly.
By doing that, I can assure you that DV is not just authenticated
point-to-point encryption - even though DV is really the lowest level
which should be used only for its intended purpose and stands just for
that. But that's not all, there are things I don't want to publicly
disclose and they are nowhere required. They still exists and contribute
nevertheless.
Having said that, of course I'm not taking responsibility for every CA
out there, but that's also the reason I'm working with Mozilla and
elsewhere to improve existing practices and remove the problematic
practices that do exist today, but are about to be addressed. I believe
this will happen rather soon and within a useful time-frame. From there
we can improve even further if possible.
Regarding DNSSEC - it will take years from now to get to an anywhere
useful level. I've seen some attempts to replace conventional X.509 PKI
trust come and go, this wouldn't be the first. However should software
vendors ever rely on DNSSEC exclusively for TLS on the web (e.g. without
third party issued certificates), I fear a disaster and SSL will become
most likely entirely meaningless. Instead I believe that CAs should take
the best out of DNSSEC for their validation procedures and this is my
intention too. Time will tell if I'm right.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
