Re: [TLS] [Uta] OCSP in RFC7525bis

[Ryan Sleevi <[e-mail]>]

On Fri, Jan 21, 2022 at 9:52 AM Daniel Kahn Gillmor <[e-mail]>
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.