On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy < [email protected]> 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. 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. 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. 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
