On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote:
> * Richard Barnes <rbar...@mozilla.com> [2014-08-01 04:09]:
> > Hi all,
> >
> > We in the Mozilla PKI team have been discussing ways to improve
> > revocation checking in our PKI stack, consolidating a bunch of ideas
> > from earlier work [1][2] and some maybe-new-ish ideas. I've just
> > pressed "save" on a new wiki page with our initial plan:
> >
> > https://wiki.mozilla.org/CA:RevocationPlan
>
> Hello,
>
> while I appreciate that something is being done, this is another
> band-aid for a system that is falling apart. Revocation is helping
> when you know that a certificate was stolen/abused but does not keep
> CAs from issuing certificates that can enable certain entities to
> mount MITM attacks. It always comes down to trusting the CAs until you
> can prove that they have done wrong.
>
> CAs have lost a lot of trust and while we still depend on them NOW I
> think it would be wise to keep working on better alternatives. When
> looking at the "Long-Range Vision" paragraph on your page I don't see
> that happening. It's rather a collection of band-aids.
>
> There is bug 672239 which would implement DNSSEC DANE to verify
> certificates/keys via DNSSEC secured DNS-Records:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=672239
>
> This bug is essentially abandoned at the moment which is really sad.
> DANE would solve all the trust problems we have right now but it seems
> no one is interested in working on it. That's especially frustrating
> when seeing how much work is now put into the OneCRL stuff.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Hi Sebastian,
While you raise an important issue, the problem(s) OneCRL sets out to
solve are still problems that need solving, and we should not lose sight.
Now, as for the problem you raise ("trusting CAs until you can prove that
they have done wrong" and "Does not keep CAs from issuing certificates
that can enable certain entities to mount MITM attacks"), it's important
to realize and remember that DNSSEC/DANE do not solve these, and in fact,
in many ways, make it easier. DNSSEC is still a single hierarchy of trust,
much like CAs, and there's still ample opportunity for malfeasance, and
there's even more opportunity for key mismanagement and insecure
cryptographic practices.
I'm not trying to defend CAs or suggest the problem you raise isn't real,
but there exist other solutions for this - like Public Key Pinning (which
Firefox implements) and Certificate Transparency, which offer more
substantial and meaningful benefits over a DANE-based solution.
Though DANE seems like a simple solution, it's one filled with errors. And
if Dan Veditz's and Patrick McManus' replies on the state of OCSP weren't
depressing, DNSSEC is an order of magnitude more depressing. Important to
keep in mind when talking "long-term vision", which is practically
achievable, and what is really "long-long-long term vision", which is more
theoretical and academic. Like DANE.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
