[websec] Requiring OCSP Stapling as a directive in HSTS

[Tom Ritter <[e-mail]>]

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