On Friday, 21 January 2022 05:51:22 CET, Ryan Sleevi wrote:
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.
Browsers are the only software that use browser's implementation of certificate
verification and revocation. And while they are significant users of TLS, they're definitely not the only important users of TLS. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
