On 2020-11-16 23:17, Ryan Sleevi wrote:
On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Hi Nils,
This is interesting, but unfortunately, doesn’t work. The 4-certificate
hierarchy makes the very basic, but understandable, mistake of assuming
the
Root CA revoking the SICA is sufficient, but this thread already
captures
why it isn’t.
Unfortunately, as this is key to the proposal, it all falls apart from
there, and rather than improving security, leads to a false sense of it.
To
put more explicitly: this is not a workable or secure solution.
Hello Ryan,
We agree that revoking SICA would not be sufficient and we mentioned that
in section 2.3 in the above message.
The new solution described in section 2.3, not only proposes to revoke
SICA (point (iv)) but also to revoke ICA (point (ii)) in the 4-level
hierarchy (RCA -> ICA -> SICA -> EE).
We believe this makes a substantial difference.
Sorry, I should have been clearer that even the assumptions involved in the
four-certificate design were flawed.
While I do want to acknowledge this has some interesting edges, I don't
think it works as a general solution. There are two critical assumptions
here that don't actually hold in practice, and are amply demonstrated as
causing operational issues.
The first assumption here is the existence of robust path building, as
opposed to path validation. In order for the proposed model to work, every
server needs to know about SICA2 and ICA2, so that it can properly inform
the client, so that the client can build a correct path and avoid ICA /
SICA1. Yet, as highlighted by
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6
, very few libraries actually implement path building. Assuming they
support revocation, but don't support path building, it's entirely
reasonable for them to build a path between ICA and SICA and treat the
entire chain as revoked. Major operating systems had this issue as recently
as a few years ago, and server-side, it's even more widespread and rampant.
In order to try to minimize (but impossible to prevent) this issue is to
require servers to reconfigure the intermediates they supply to clients, in
order to try to serve a preferred path, but has the same operational impact
as revoke-and-replace, under the existing, dominant approach.
Correct, thus most affected EE-certificate holders would still have to
reinstall the certificate configuration for their (unchanged) EE cert,
which is still less work than requesting and getting a new certificate.
The second assumption here is with an assumption on robust CRL support,
which I also hope we can agree is hardly the case, in practice. In order
for the security model to be realized by your proposed 4-tier plan, the
clients MUST know about the revocation event of SICA/ICA, in order to
ensure that SICA cannot spoof messages from ICA. In the absence of this,
the risk is entirely borne by the client. Now, you might think it somehow
reasonable to blame the implementer here, but as the recent outage of Apple
shows, there are ample reasons for being cautious regarding revocation. As
already discussed elsewhere on this thread, although Mozilla was not
directly affected due to a secondary check (prevent CAs from signing OCSP
responses), it does not subject responder certificates to OneCRL checks,
and thus there's still complexity lurking.
Actually, for the current major browsers, the situation is better:
1. Chrome would distribute the revocation of the "ICA" cert in it's
centralized CRL mechanism.
2. Non-chrome Microsoft Browsers would actually check CRLs and or OCSP
for the root CA to discover that the ICA cert is revoked. This would
be done against the CRL/OCSP servers of the root CA, not those of ICA.
3. Firefox would distribute the revocation of ICA (or any other
intermediary CA) through its centralized "SubCA revocation" mechanism.
As it relates to the conclusions, I think the risk surface is quite
misguided, because it overlooks these assumptions with handwaves such as
"standard PKI procedures", when in fact, they don't, and have never, worked
that way in practice. I don't think this is intentional dismissiveness, but
I think it might be an unsupported rosy outlook on how things work. The
paper dismisses the concern that "key destruction ceremonies can't be
guaranteed", but somehow assumes complete and total ubiquity for deployment
of CRLs and path verification; I think that is, at best, misguided.
Although Section 3.4 includes the past remarks about the danger of
solutions that put all the onus on application developers, this effectively
proposes a solution that continues more of the same.
As a practical matter, I think we may disagree on some of the potential
positive outcomes from the path currently adopted by a number of CAs, such
as the separation of certificate hierarchies, a better awareness and
documentation during CA ceremonies, and a plan for agility for all
certificates beneath those hierarchies. In effect, it proposes an
alternative that specifically seeks to avoid those benefits, but
unfortunately, does so without achieving the same security properties. It's
interesting that "financial strain" would be highlighted as a goal to
avoid, because that framing also seems to argue that "compliance should be
cheap" which... isn't necessarily aligned with users' security needs.
Only tangentially related to this discussion. This entire situation
arose out of an inconsistency between policy requirements/best practices
for the OCSP EKU and for any other EKU OID. CAs that applied the
general EKU chaining policy/best practice to SubCAs authorized to issue
their own OCSP-signing end-certs would inadvertently violate the letter
of the OCSP policy requirements and cause a potential for misuse by
authorized 3rd party SubCAs.
I realize this is almost entirely critical, and I hope it's taken as
critical of the proposal, not of the investment or interest in this space.
I think this sort of analysis is exactly the kind of analysis we can and
should hope that any and all CAs can and should be able to do. I think if a
CA had done such a fantastic write-up, as you have here, for a very
specific situation, it would have been very positively reflected on the CA,
regardless of whether it was accepted as a mitigation. We should expect CAs
to be the very best of us, to hire the very best, and to be the very best
at explaining. Unfortunately, as your post highlights, CAs have largely
optimized for reducing "financial strain", and thus, haven't really tried
to be the best or have the best. And I think, for users, that's unfortunate.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
