Subject: [websec] Requiring OCSP Stapling as a directive in HSTS

From: Tom Ritter <[email-masked]>
Date: Mon, 19 Jan 2015 11:55:39 -0600

Hi all.  I'd like to propose an idea: add an optional directive to the
HSTS header that, when included, mandates any certificate received for
a domain require OCSP Stapling. It would respect includeSubdomains and
max-age.

The threat model I'm trying to address is an attacker who can get a
valid certificate misissued for a domain.  Because of the revocation
situation, the attacker can then MITM users with impunity, blocking
revocation lookups if they occur.  While UAs would receive a crlset or
other push of revoked certificates, I believe that the UA will still
work if that connection is blocked, and it's not clear how long that
connection must be blocked before the UA stops working entirely.  (If
that happens at all.)

Counting from the detection of the attack (which efforts like CT and
Pinning help detect), requiring OCSP stapling changes the window of
attack from {forever?, 30 days?, an unknown value?} to the OCSP
staple's lifetime.  (Assuming the attacker gets a OCSP signature right
before revocation.)

Why OCSP stapling and not require the UA to instead use 'hard-fail'
revocation checking?  Well, CRLs have all sorts of drawbacks: longer
expiry times, large sizes, and they're pretty much being phased out
everywhere.  (I know about Delta-CRLs - developing a specification for
them, implementing, and deploying them will take years, if ever, due
to IPR stuff. This does not.)   What about requiring OCSP querying?
Browsers don't much care for that - it's slow, can timeout for
non-security reasons, it's out of the control of the web site owner.
That leaves us with OCSP Stapling - it's fast, implemented, deployed.

While I'm not opposed to making the language say "Hard Fail Revocation
Checking" I would expect UAs to interpret that as OCSP stapling, and
would not want to delay implementation to account for unlikely-used
corner cases.  And if we say OCSP Stapling, there's no reason that
down the road we could add a new directive for 'hard-fail-revocation'
and let it encompass many different checks.

As far as 'Where?' and why 'In HSTS'?  I see four options: a HTTP
Header, a TLS Extension, a DNSSEC record, and a Certificate Extension.

Certificate Extension is being worked on
(https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/) but I
see it as a compliment to this.  The certificate extension only
dictates policy for this certificate.  If we assume an attacker can
get a misissued certificate for a domain, the cert extension is only
useful when it is the default issuing status and an attacker must have
additional privledges to circumvent it.  And it doesn't make sense to
have a certificate extension dictate policy for a whole domain, that's
a very strange location to put this sort of data.

A DNSSEC record has deployment problems, we can't retrieve it
reliably. Fallback or soft-fail provides no security and is useless
here.

A TLS Extension makes a certain amount of sense.  We're trying to
dictate a policy for TLS connections, not HTTP.  But it's more
difficult to deploy TLS Extensions than HTTP headers, the TLS working
group is tremendously busy, and technically this would fit more with
the closed PKIX group.

That leaves us with a HTTP Header.  I think it makes more sense to put
this as a directive on HSTS rather than making a new header. While I
could imagine situations where one would want to require revocation
checking (or pinning for example) without requiring TLS, I don't see
it as a huge use case.  Rather, putting it in HSTS is a small
incremental upgrade that avoids redefining all the other stuff.

Should the UA require a staple for all certs in the chain
(Intermediates included) or just the leaf?  I'm not religious about
one or the other, I'd probably lean towards requiring all but I'd need
to review the implementation and deployment status of multi-stapling.
Just requiring the leaf is simpler from a deployment perspective I
believe, and compromised intermediates cause immediate browser pushes
anyway.

Would there be support for this draft?

-tom

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 19 Jan 2015 11:17:14 -0800

>  connection must be blocked before the UA stops working entirely.  (If

In this threat model, where does NTP fit? It seems like you're assuming
the attacker can intercept both the target site and the UA's distribution
mechanisms, so I would presume that they're also privileged enough to
mount NTP attacks?

>  and let it encompass many different checks.

To make sure this is clear: You're suggesting hard-fail OCSP checking when
the OCSP directive is present in the header (always), and you're just
quibbling over the naming of that directive here, right?

I'm just making sure, since soft-fail OCSP stapling doesn't seem to make a
lot of sense?

>  Header, a TLS Extension, a DNSSEC record, and a Certificate Extension.

You missed a fifth.

A .well-known URI (RFC 5785) used to configure security-policy at the
domain level.

I don't suggest this as something that the browser would background fetch
(although certainly, it could be induced so coupled with a header).
Moreso, I'm suggesting that this be used to build such preload lists of
security policy so that they can be distributed.

The failure mode of a bad HSTS header is not too bad - you're stuck on
TLS. If accidentally set / by an attacker / things really hit the fan, you
could stick one of the many CDNs in front of your site to handle the TLS
to your unencrypted backend.

The failure mode of a bad HPKP header is decidedly worse - total site
denial if you do key rotation / change CAs. Preloading is one way to
mitigate this (by providing some consistent view of effective policy),
although even that can be botched (e.g. CryptoCat recently rotated CAs and
thus committed pinning suicide, at least until Chrome 41). The security
considerations of hostile pinning alone accounted for quite a bit of
discussion.

OCSP stapling I think falls somewhere in the middle here on the risk
proposition - there's still a vast, depressing majority of server software
that doesn't support OCSP stapling. What are the implications for server
admins who botch it themselves or who are attacked? I'm much more
concerned by the former, see it much more likely, and think it's much more
likely to result in self-inflicted DOS. For example, configuring ngingx to
serve an OCSP response, but then forgetting to setup the cron job to
rotate it = site inaccessible once the response expires (presuming hard
fail, which I think is the sensible path)

The advantage (or disadvantage, depending on your POV) of a .well-known
URI + preloading allows some degree of curation of policy for sanity,
which can't be expressed by a point-in-time snapshot of headers (at least
for HPKP and for this hypothetical OCSP must staple)

>  a very strange location to put this sort of data.

To be fair, the certificate extension is dictating policy for the
certificate. You're absolutely correct, however, that misissuance without
including that extension is undetectable from CA rollover.

>  group is tremendously busy, and technically this would fit more with

Doesn't this suffer many of the attendant issues you raised with a
certificate extension? Namely, that the MITM attacker who has obtained a
fraudulent cert (since that would be the only reason I can think of to
worry about OCSP stapling) would just not send the extension.

Or are you implying that the extension would/should have a persistence layer?

>  incremental upgrade that avoids redefining all the other stuff.

I'm not sure this makes sense. You highlight early on the desire to make
includeSubDomains and max-age behave the same, but I can also think of
reasons why you would want them separable.

>  believe, and compromised intermediates cause immediate browser pushes

Only the leaf. Sending the intermediates is (generally) wasteful and
redundant for the connection warm-up, and any intermediate misissuance
(which, we should hope, is rare) is already a browser-level event.

I note this is also consistent with Mozilla's past statements on
revocation ( https://wiki.mozilla.org/CA:RevocationPlan ) - where
intermediate revocations are managed by the browser and leaf certs are
left for stapling.

>  Would there be support for this draft?

How does this proposal fit into a world where UAs might begin to _always_
require OCSP stapling? Perhaps only for some certs, at first, but say in 5
years, would this be as relevant?

https://groups.google.com/a/chromium.org/d/msg/security-dev/jmbbIgmGbdk/xU8pR8fxYOYJ

---

From: Tom Ritter <[email-masked]>
Date: Mon, 19 Jan 2015 18:57:57 -0600

> mechanisms, so I would presume that they're also privileged enough to

That's true.  It would be broken by NTP and an attacker attaching an
older OCSP staple.  (Similarly, an attacker could use an old staple
and a previously compromised certificate, one since expired.)

The best proposal I've heard for fixing NTP was using TLS (either in
the protocol or an HTTP Date header) for broad resolution plus NTP for
fine-grained skew.  I'd love to see OSes and/or UAs adopt it.

> I'm just making sure, since soft-fail OCSP stapling doesn't seem to make a

I'm definitely not proposing soft-fail anything.

I was dancing around options for what the directive would mean, trying
not to be too religious about it:
a) Call it "Require OCSP Stapling"
b) Call it "Require Hard Fail Revocation Checking" and UAs really
implement it as requiring a Staple
c) Call it "Require Hard Fail Revocation Checking" and UAs implement
it as requiring a CRL, Staple, or Successful OCSP query

I like (a), followed by (b), and least of all (c).  I think (c) is the
most work and is going backwards from what UAs seem to want - so least
likely to be implemented.

> (although certainly, it could be induced so coupled with a header).

I'm not sure I understand: there's a .well-known URL that says "Must
Staple" _and_ a header?

> security policy so that they can be distributed.

I'm not sure I understand you entirely, but if you're suggesting that
the crawl +  browser preload is the mechanism by which this is
deployed, I'm kind of 'meh' on that.  It relies on a site operator
inducing a company to crawl their site and bake the policy into the
software somehow.  It feels like taking something that's two-party
(site operator and user agent) and making it three (adding user agent
infrastructure and crawling robots).

> fail, which I think is the sensible path)

DoS is definitely something to be addressed in a section.  I agree
it's between HSTS and HPKP, but it feels like it's not a huge bump
above HSTS.  We would definitely want to mandate that the directive
not be noted unless it was received over a connection that had an OCSP
staple, similar to how HSTS or HPKP are noted.

The 'worst case scenario' of getting it set and you can't support it
is pretty similar to the worst case scenario of HSTS. You have to
stick some sort of proxy or CDN in front of your site.  If your site
already handles HTTPS (e.g. no infinite redirects
HTTP->HTTPS->HTTP->...) then it's even easier as you can terminate
your TLS connection from your webservers and re-encrypt with your
OCSP-providing proxy.

> for HPKP and for this hypothetical OCSP must staple)

It does, but only because you've moved the complexity from the User
Agent to the crawler.  One example of the complexity would be Trevor
Perrin's ideas for TACK/HPKP where you first note it for X amount of
time, and then if you see it again you note it for X*2, and so on.
Another could be human-curation.

> Or are you implying that the extension would/should have a persistence layer?

Yes, it would only work if the TLS extension had a persistence layer.
Which is awkward in TLS.

> reasons why you would want them separable.

Yes, certainly.  You may only want OCSP Stapling on for a hour while
you test it out, you can't deploy it across all subdomains, etc.  The
most amount of flexibility would be to make it it's own header (or
.well-known).    HTTP 2.0's header compression may mean we don't care
that much.  I don't have a strong preference, I was trying to strike a
middle ground.

>>  (Intermediates included) or just the leaf?
>
> Only the leaf.

Sure

> https://groups.google.com/a/chromium.org/d/msg/security-dev/jmbbIgmGbdk/xU8pR8fxYOYJ

Well no, if UAs require OCSP Stapling for every site they visit it's
not relevant at all.  But I think 5 years is an impressively
aggressive timeframe for getting to the point of throwing up a
interstitial for lacking a staple across the whole internet.

I recognise it's not just my work that would be made redundant, it
would be many's, but still I would be happy to have it made redundant
if in 4 years all popular UAs actually achieved that goal.  It seems
doubtful though, so I'm not willing to bank on it.

-tom