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

[Tom Ritter <[e-mail]>]

On 19 January 2015 at 13:17, Ryan Sleevi <[e-mail]> wrote:
> On Mon, January 19, 2015 9:55 am, Tom Ritter wrote:
>>  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.)
>
> 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?


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.


>>  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.
>
> 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?

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.


>>  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.
>
> 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).

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

> Moreso, I'm suggesting that this be used to build such preload lists of
> 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).


> 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)

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.


> 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)

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.


>>  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.
>
> 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?

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

>>  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.
>
> 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.

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.


>>  Should the UA require a staple for all certs in the chain
>>  (Intermediates included) or just the leaf?
>
> Only the leaf.

Sure

>>  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

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