On Mon, Dec 10, 2018 at 9:03 AM Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> On Mon 2018-12-10 02:24:29 +0000, Salz, Rich wrote: > >> * the status_request TLS extension doesn't provide a mechanism for > > stapling OCSP for intermediate certs. > > > > Nobody does this. There's a handful of reasons, but the end result is: > nobody does this. > > I'd be interested in hearing the reasons enumerated. It seems to me > like being able to promptly revoke an intermediate certificate is a > useful bit of mechanism. is it just because we hope the major browsers > are clever and responsive enough that they'll push out a CRLset (or > equivalent) when they hear of an intermediate that is found to be > violating the BRs? > A few more reasons - speaking broadly to the "revoke intermediates" problem: * The traditional revocation model (of CRLs and OCSP) is not as robust as browser-based methods. - OCSP & CRLs both do the (Issuer+Serial number) dance, while alternative revocation methods can use use the (Subject+SPKI), or even just the (SPKI), as a blacklisting mechanism. - In the case of stapling responses for Intermediates, it's not sufficient to 'simply' staple the response for the given intermediate - it would have to consider all possible intermediates that chain to trust anchors (both public and locally-configured). * It's inefficient for the stated goal, under an adversarial model. This applies to both leafs and intermediates. - While TLS 1.3 has the potential to make this better [1], the intermediate response is generally going to be highly common between multiple connections. There's no way (AFAIK), under V2 or 1.3, to indicate that you already have a suitable response regarding a particular intermediate. Past proposals [2] ran into a whole host of sharp edges of complexity here; if memory serves, that complexity is very similar, in terms of security/privacy/performance tradeoffs, as some of the cache digest proposals [3] - bloom filters abound :) - If a client doesn't support it (and, indeed, only Microsoft provides the relevant APIs in a safe way [4]), it's wasted bytes. Unlike status_request_v2, AFAIK, there's no way for a 1.3 client to signal it's uninterested in those intermediates; whether because it doesn't support them or because it has alternative means. * It's slow, under an adversarial model. - For leaves, we're talking 7 days of reusable "GOOD" response from an adversary - the maximally permitted time under current root programs, less than the 10 days the CABF BRs allow. For intermediates, as Ilari mentioned, this becomes a substantially greater timescale. And this is without touching on some of the ambiguity CAs rely on - the difference between marking in their (internal only) database that a certificate is revoked versus making that information publicly available (aka distributed to their CDN). I'm told lag times may go up to an additional 7 days there. - For intermediates, this is "12 months". Some efforts to profile this down [5] resulted in non-trivial pushback, given that many non-actively-issuing certificates (offline roots/intermediates) require ceremonies for the use of the key material - such as delegated responders (which then opens up a whole new can of worms regarding compromises of responder certificates - given id-pkix-ocsp-nocheck in the responders) And this ignores some of the other "technical but not fundamental" problem, such as few servers actually perform any form of path building or validation on the certificates they will serve, and largely leave that to the server administrator to configure. The lack of robust OCSP stapling infrastructure for leaves - for which Microsoft IIS or Caddy may be the only COTS server software robust enough to handle it - is dwarfed by the complexity of also considering path building, possible paths, and finding the 'ideal' intermediate and response to serve to avoid the known challenges, let alone the challenges for some of the issues above. To your specific question about the semantics for TLS 1.3, I don't think that proposed semantic shift is good or desirable. I think it will both increase inefficiency and fail to achieve the desired security properties, as a consequence of the reasons above. Happy to expand on that, if it does not seem like the conclusion logically follows the enumeration of problems. That said, I also acknowledge that there aren't plans, at this time, to support for "TLS Feature" extension, due to the policy and availability implications, which are not technical and a consequence of the Web PKI specifically. [1] https://tools.ietf.org/html/draft-ietf-tls-certificate-compression [2] https://github.com/hannestschofenig/tschofenig-ids/tree/master/tls-cached-info Hannes could speak to better threads capturing these discussions, no doubt [3] https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest [4] https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-certsetcertificatecontextproperty with CERT_OCSP_RESPONSE_PROP_ID allows per-certificate handle setting; NSS uses https://dxr.mozilla.org/nss/source/nss/lib/certhigh/ocsp.c#5073 , which is per CERTCertificate handle, except those can get shared between connections, resulting in clobbering of the OCSP cache by 'adversarial' peers. Of course, Firefox ignores this with https://dxr.mozilla.org/mozilla-central/source/security/certverifier/NSSCertDBTrustDomain.h?q=%2Bfunction%3A"mozilla%3A%3Apsm%3A%3ANSSCertDBTrustDomain%3A%3AGetOCSPStaplingStatus%28%29+const"&redirect_type=single#162 .. For Apple, https://developer.apple.com/documentation/security/1400880-sectrustsetocspresponse?language=objc exists but doesn't provide any (documented) way of binding the response<->certificate pairs. [5] https://github.com/sleevi/cabforum-docs/pull/2/files
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
