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
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
