Re: [TLS] [Uta] OCSP in RFC7525bis

[Ryan Sleevi <[e-mail]>]

On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor <[e-mail]>
wrote:

> This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT".  Why would a
> client deliberately fail a connection when the problem might be a flaw
> with an unrelated network service or a client-specific routing failure?
>
> I think we can definitely explicitly recommend:
>
>  A) clients MUST require valid stapled OCSP response when encountering a
>     certificate with "must staple" extension.  (this is just following
>     the specs, but i don't think it's as widely supported as it should
>     be; maybe we need some public naming/shaming?)
>

Isn't this also a "MUST, BUT WE KNOW YOU WON'T AND PROBABLY SHOULDN'T"?

There are good reasons that clients have not, and potentially will never,
support Must-Staple, whether it be for the technical reasons that many
servers are unfit to support it, or for policy reasons, such as wanting to
be careful about the security policies of their products, and how much of
that is outsourced to CAs. 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. 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. For example, in a world where a client delivers
revocation information out of band, as nearly every major web browser does
today (as one example), "must staple" is of questionable benefit.


> So the right set of fixes to defend against all these kinds of attacks
> are:
>
> - enable DNSSEC for your zone
>
> - signal in your DNS (e.g. via CAA, RFC 8659) that you only want a
>   specific set of CAs to issue certificates in your zone (CAA doesn't
>   explicitly describe an option to require that the CA use must-staple,
>   but it looks like any CA could declare a CAA parameter that would
>   offer that guidance.  for example:
>   https://github.com/letsencrypt/boulder/issues/5903)
>
> - ensure that your account with those CAs requires must-staple (either
>   with your CA's preferred CAA parameter, or some other way)
>
> - monitor CT logs for certificates that violate your CAA policy
>
> This should close all the gaps that i can see, making the whole chain as
> strong as your control over what gets signed by your zone's DNSSEC
> signing key (and your CA's adherence to CAA policy, of course).
>

Without wanting to detract too much from the core question of the thread,
how does this address the routing gap? The adversary at the routing layer
just redirects the host being validated to control the key that way, and
simply interrupts the nameserver during the CAA check. In the threat model
you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA
checks.

The assumption here for this model to hold is that the CAA information is
infallibly guaranteed to be delivered to the CA (it is not), and that the
CA will properly adhere to it for all threats that are concerning (they do
not). Without those properties, this doesn't provide any value, and that
rather significantly undermines the argument for the MUST for Must-Staple
being made for clients/relying parties.