On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor <d...@fifthhorseman.net> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
