On Fri, Jan 21, 2022 at 9:52 AM Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> I share your skepticism, but i'm still trying to salvage something > useful -- for the purpose of defending against CA malfeasance -- from > the mechanisms we have available. > Indeed, I think the goal is admirable, but I'm not sure these technologies are the right way to achieve this. > Of course a client is free to ignore what the CA says and accept the > certificate anyway. But once you're ignoring what the CA actually wrote > and signed in the certificate, you're on your own. > There is an ample amount of information that CAs can put in certificates which are not processed or are not relevant to achieving a particular goal. The distinguished name is one such example (of having limited technical value in practice, other than as an opaque ID), but equally, elements like policy qualifications are another. In theory, systems could try to process these, and there's no question that some non-Internet focused SDOs do try to do this (e.g. the Qualified Certificate specifications and expressions), but those are somewhat at odds with the goals mentioned in RFC 5280, Section 2.3. This may sound a bit abstract and wishy-washy, but my point is that not everything a CA puts in a certificate is necessarily aligned in the interests of relying parties, users, and server operators. If we had an X.500 directory, in which the choice of a given PKI was an emergent property discovered from The Directory, this is a non-issue for server operators, because any server operator can simply declare a new set of CAs for their organization. Similarly, in a model of DANE, in which DNS becomes the source of truth for discovering who your chosen CA is, this is also a non-issue. Yet in a model in which we work from common trust bundles, including things like Qualified Trust Lists, there's an imbalance created, and thus the ability to decline a CA that works against the server operators interests is non-existent. All of the previous solutions equally have issues for reflecting the end-users interests - if your DANE entry uses RSA-1024 or expresses an authorization for an RSA-1024 bit key, that's not necessarily aligned with end users/relying parties. So the statement that "But once you're ignoring what the CA actually wrote and signed in the certificate, you're on your own" is, I think, taking the classic X.500 approach, that everything the CA asserts is of equal value and merit, and if it wasn't, server operators would chose a different CA. The reality we have is somewhat different, in which relying parties/end users/user agents authorize CAs to make some assertions (e.g. domain validation), but do not necessarily trust them or use other expressions. A concrete example of this is Logotype, which is widely ignored. > > The choice about whether to require stapling or not _is_ a policy > > decision relevant not only to server operators, but also relying > > parties, and can be easily abused by CAs if given that lever. > > What kind of abuse are you anticipating here? can you spell it out in > more detail? > You may want to check the mozilla.dev.security.policy discussions going on around the topic of revocation, as Mozilla tries to narrowly define the scope of reasons that CAs use for certain types of revocation. Concrete, real world examples we see in the Web PKI case: 1) If you get a single certificate from any other CA, we will revoke all of your certificates. 2) If there is a business dispute, we will revoke your certificate. 3) If any entity claiming to be associated with any government or regulatory body (even without evidence of association) claims we need to revoke your certificate, we will revoke your certificate. 4) If any content posted on your website is something we disagree with, we will revoke your certificate. 5) We do not "issue" certificates, we "rent" you certificates at a variable monthly rate. If you fail to pay the increase / fail to maintain X certificates with us, we will revoke all your certificates. These are interests of revocation that may not be in the interests of server operators or end users, but these are entirely understandable positions that CAs may take. This is partly why the real world of revocation is so complex, even setting aside the many technical issues. A policy such as clients MUST support Must-Staple is an example of further centralizing that control and (implicitly) power/privilege to the CA. I recognize and agree that Section 4.2.3.1 of RFC 7633 lives a policy hole you could drive a truck through, and that would easily be used to justify the lack of implementation of a MUST today. So the MUST doesn't necessarily add value here, other than elide the complexity of the space, and disregards both the technical and policy tradeoffs that exist for why clients have largely not yet adopted this. > > Given the concerning practices already seen with respect to > > revocation, which are detrimental to the security goals of both server > > operators and end users, a full-throated MUST seems a bit incompatible > > with the notion of allowing policy flexibility. > > Do you think that a MUST validate the intended DNS name against the sAN > in the certificate is also incompatible with the noton of allowing > policy flexibility? > It's not clear to me if this is a rhetorical question, because it's not clear how it follows from the previous remarks. Hopefully, the above remarks clarify that the extent of expectation on the client needs to be aligned with the degree of trust and delegation of certain actions to CAs, and different actions (e.g. validation vs revocation) are not at all created or treated equally. Again, this is an artifact of the lack of a global directory (which allows any CA, whether in long-existence or created seconds ago) to be used, and the need for some degree of pre-provisioned distribution to be effectively used. Because that selection is limited, and because all are functionally equivalent, a greater degree of skepticism to the privileges afforded to them is necessary. > do major web browsers deliver revocation out of band for end entity > certificates? My impression was that most CRLSets would only be updated > and pushed for known-compromised CA certs (intermediate or root) and > very widely-visited end entities. I don't think a small end entity will > benefit from CRLSet distributions, but i'd love to be wrong. > Every browser has different priorities, recognizing the degree of deference they give to CAs for certain actions. However, systems like Valid (Apple) and CRLLite (Mozilla) do attempt to be more representative samples of the set of certificates. There's significant debate as to the degree of meaningful security, in a Web/HTTPS platform, that such systems provide, but they are trying to provide more holistic datasets - albeit at significant greater upfront cost to users. IIRC, it's ~50MB for Apple, ~1MB for Mozilla, both of which are fairly prohibitive for mobile devices, but still amortize better than a MUST of OCSP-Stapling, which simple back of the napkin math against public statistics from browsers like Firefox show would be massively cost-prohibitive in connection overheads. > If DNSSEC is soft-fail for the CA verifying CAA checks, then i agree > this is insufficient. The letsencrypt implementation is apparently at > least logging the info about DNSSEC signatures. > > https://github.com/letsencrypt/boulder/issues/2700 > > Do you think that DNSSEC should be soft-fail for CAA checks, or should > we urge the CAs to be more strict here? Perhaps that would be another > recommendation. > I don't think that recommendation is germane for this discussion, at the least. I think it's a broader policy question, and perhaps for a different community, but I wanted to highlight it precisely because the conclusions for this discussion somewhat rested upon it. I totally appreciate the "chicken and egg" question here about which we fix first (similar to the old DoH/DoT vs SNI), and I'm not trying to "whatabout" as a means of delaying improvement, but it very much is a systems problem, and we need to think about solutions as systems solutions, before trying to rush out recommendations. That's why I think the OCSP question, broadly, is one that isn't yet ready here. > I agree that CAs are not guaranteed to follow the policy guidelines. > However, a server operator can choose a CA that it believes *will* > follow this guidance, and use a CAA record to indicate that all other > CAs would be misissuing if they grant a cert for the operator's name. > Then they can use CT to identify the misissuing CA, and use, uh, > political(?) channels to try to get that CA taken down for failing to > meet the BR. That's where the CRLSet comes in, right? > > This is a teetering chain of ugly dependencies. I'm not very happy with > it. But i don't see what the alternative is in the current landscape if > we want folks to be better protected against misissued certificates. > I think you're assuming that CAA is sufficient to prevent misissuance, but it isn't. We continue to see examples of CAs who failed to do any validation of domains or IPs, and even further, those CAs refusing to revoke those certificates for weeks after the fact, because they didn't think it was an issue. While mistakes happen, I think the assumption here of CAA's value combined with Must-Staple, or OCSP in general, is overstated, because it assumes a "well-behaved CA" as part of the threat model. Both in terms of revocation, but also in issuance, we know mistakes are regularly being made, and so the positive benefits here are overstated, particularly under an adversarial model. An adversary who bypasses CAA both bypasses the expressed desire for Must-Staple _and_ the restriction on who the CA can be, thus providing no security benefit to the end user.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
