I was trying to sort out concrete, specific advice for OCSP stapling that provides security benefits for the server (and not just performance and privacy benefits). Either i'm easily confused, or it's a mess. I hope it's the former, please unconfuse me!
Given the IAB's statement from nearly two years ago about the value in OCSP stapling [0], it's a little distressing to me how difficult it seems to be to get it right in today's landscape. [0] https://mailarchive.ietf.org/arch/msg/ietf-announce/j0JIIGhD-xvbaWxtGm2-pFK0JQ8 In the bullet points below, i'll refer to the status requester as the "client", and the party returning the status as the "server". I'm aware that the roles could be reversed if the server is requesting client certs, but i'm going to punt on that wrinkle for now, since the straightforward/common case is confusing enough. * the status_request TLS extension doesn't provide a mechanism for stapling OCSP for intermediate certs. * the status_request_v2 extension does provide a mechanism for stapling intermediate OCSP, but it is deprecated by TLS 1.3 and TLS servers responding with a TLS 1.3 handshake MUST NOT send status_request_v2 in the ServerHello. * the location of the stapled response has changed between TLS 1.2 and TLS 1.3 -- in 1.2 and below, the OCSP response data is carried in a CertificateStatus message. In 1.3, it's in an Extension object associated with a Certificate, which allows certificate stapling for intermediate certs. this is a good thing! but a TLS client capable of both 1.2 and 1.3 that wants to be rigorous about stapling in both protocol versions has a much more complicated set of logic to worry about. * the certificate_status extension has its own internal extension point: enum { ocsp(1), (255) } CertificateStatusType; This goes against the "have one joint, and keep it well-oiled" design pattern we've learned over the years, because now you have the extension itself (certificate_status) and its own config selector. This results in another 8-bit registry to maintain: [1] [1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#certificate-status I think we should have omitted this additional joint, and just defined the certificate_status extension to be ocsp_status, without this field. If someone wants to introduce a new status type, they can introduce a distinct TLS extension later. * I see no requirement that the CertificateStatusType in the CertificateStatus record actually matches the CertificateStatusType in the status_request extension sent by the client. * In TLS 1.2 and earlier, there is no obligation for a server which replies with the certificate_status extension to actually publish a CertificateStatus message. * Furthermore, if a status_request arrives at a TLS 1.2 or earlier server with a CertificateStatusType other than ocsp(1), or with non-empty ResponderID or Extensions members, it's conceivable that the server couldn't accurately create a corresponding OCSP response (either because it does not know about, or cannot contact any of the requested OCSP responders, or is for whatever reason unable to apply the requested OCSP extension(s). * the TLS Feature Request x.509v3 extension only indicates which extensions are supported in a generic, per-extension way. So while a CA might be able to assert "this server will always reply with a status_request extension for this certificate", it doesn't appear to guarantee that (in 1.2) the server will actually send a CertificateStatus message at all, even if a status_request extension is sent, let alone whether the contents of that CertificateStatus message will be related to the client's status_request. And in 1.3 it doesn't guarantee that status_type will be ocsp(1) for the status_request extension that is sent. * Without the TLS Feature Request x.509v3 extension in the server's cert, there's no way to ensure that a compromised server can't just block the client from ever learning any OCSP details (e.g. by controlling the client's network). So i think this is a big swirling mishmash of not-quite-compatible and not-quite-complete specs, especially as we think about TLS clients and servers that want to be interoperable with both TLS 1.2 and TLS 1.3. In trying to figure out reasonable, useful guidance, and to make the TLS Feature Request X.509v3 extension somehow useful, i'm tempted to try to write up a clarifying/simplifying specification that actually cleans up some of the semantics of status_request by cleaning up and enforcing the currently-expected semantics. In particular, i would want to propose something like: * regardless of TLS version, clients SHOULD NOT send status_request_v2, and servers SHOULD NOT return it even if the client supplies it. If you want stapling for your intermediate certs, you need to have negotiated TLS 1.3. (i think this is in line with the deprecation announced in 8446) * ask IANA to lock down the CertificateStatusType registry, or maybe remove it altogether. status_type would then become just a legacy fixed value of 0x01 ("ocsp") * clients SHOULD always send ResponderID of length 0 and rely on the server to select an OCSP responder based on the AIA X.509v3 extension's "OCSP" and "CA Issuers" fields in the server's certificate's X.509v3 extensions. * i'm not sure what to do about the Extensions field in status_request. For simplicty's sake, i'd like to say it should always be empty. how much would we lose if we lost the ability to force in id-pkix-ocsp-nonce. * I'd like to redefine the semantics of what the TLS Feature Extension means for X.509 if it includes the status_request integer (5). In TLS 1.2 and earlier, it means that if the client sends a status_request extension, a server MUST always send a CertificateStatus message after its Certificate message, and that CertificateStatus message MUST have status_type set to ocsp(1). for TLS v1.3, it means that each CertificateEntry that contains this cert should also have a status_request extension, and that the extension's contents should match the expectations for v1.2 CertificateStatus messages described above (e.g., status_type=ocsp(1), no ResponderID). additional conclusions for CAs ------------------------------ * CAs must not issue certificates with a TLS Feature extension that indicates status_request_v2 for any server that intends to use the certificate with TLS 1.3, since TLS 1.3 servers are prohibited from responding with status_request_v2 extensions anywhere. what do folks think of the above simplifications and subtle shifts in semantics of already-defined code? Is it worth trying to collect all this into a single document with clear guidance to implementers, and a promise that we will not extend status_request to non-ocsp mechanisms, so that the X.509 TLS Feature Extension can be meaningfully applied for this purpose? Or does such a document already exist? should we be encouraging stapling as much as possible for security, in addition to performance and privacy enhancements? --dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
