Re: [TLS] OCSP Stapling confusion

[Ryan Sleevi <[e-mail]>]

On Mon, Dec 10, 2018 at 9:03 AM Daniel Kahn Gillmor <[e-mail]>
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