Re: [TLS] [Uta] OCSP in RFC7525bis

[Daniel Kahn Gillmor <[e-mail]>]

Hi Ryan--

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.

On Thu 2022-01-20 23:51:22 -0500, Ryan Sleevi wrote:
> 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.

If certificate validation is the process of confirming what a CA says,
then a CA that has said "this certificate should not be considered valid
unless you also have a reasonable proof of freshness" is pretty
unequivocal.  maybe the MUST should be "MUST NOT accept unless a
reasonable proof of freshness is available, for example a stapled OCSP
response"?

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.

https://datatracker.ietf.org/doc/html/rfc7633#section-4.2.3.1 only says
"SHOULD" here, but then it's a bit fuzzy about the exceptional cases for
the "SHOULD".  the first paragraph of exception is "if it has some other
proof of freshness", and the second paragraph is "if you'd fallback to
cleartext anyway" -- does the final caveat of "MUST NOT distinguish that
connection as secure" refer to both cases, or just the latter?

> 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?

> 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?

> 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.

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.

> 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.

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.

> 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).

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.

> 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.

I don't see why it undermines the MUST for RP's supporting Must-Staple.

fwiw, this whole revocation system seems much closer to "so complex
there are no obvious problems" than "so simple that there are obviously
no problems" :(

   --dkg