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

["Ryan Sleevi" <[e-mail]>]

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?

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

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

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

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.

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

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

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

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

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