On Thu, Jan 20, 2022 at 8:41 AM Hanno Böck <ha...@hboeck.de> wrote: > Thus even if you think OCSP stapling and the whole process of revocation > is useless, there are still good reasons for a server operator to enable > stapling: > 1. It avoids an extra connection for clients to the OCSP server, thus > making client connections potentially faster. > 2. It avoids a potential privacy issue for clients who would otherwise > leak their intent to connect to a specific host to their CA.
Without wanting to debate the merits too much, because I am cognizant that opinions are mixed, I would want to push back on the first assertion there. >From a server perspective, this involves potentially sending the response on every connection, where a client initiated (or out of band delivered) request would amortize that cost over the lifetime of the response. That is, in the context of RFC 5019, which has long been seen as the only “internet scale” way to deliver OCSP (by leveraging HTTP and intermediary/CDN caching), the client doesn’t need to request a new response for the lifetime of the response/caching directives. However, in the server stapled case, it is not able to effectively / safely slide that. There was a lot of discussion about this imbalance during the discussion of TLS cached info, and the tradeoffs there, but I hope we can agree that even then, it’s not widely supported. In practice, for most clients, OCSP stapling will add non-trivial overheads to the connection establishment, especially given the lack of widely adopted OCSP response profiles and practices (e.g. CAs including more certificates than necessary). I don’t dispute the theoretical value of your second point, and the nature of the chicken-and-egg problem of “If a client wants privacy, should it rely on the server to change, or should it change” (which we see similarly playing out with things like DoH or ECH). However, it’s worth highlighting that OCSP stapling is not the only way to achieve those privacy goals, and it’s not as low cost as your first point suggests. Unsurprisingly, this means I agree with EKRs recommendations for the path forward on this draft, namely, avoiding the SHOULD. It would be interesting to explore that tradeoff space, as he suggests, but I realize that this discussion likely highlights that it will be a delicate needle to thread to do so in a timely fashion. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
