[websec] Requiring OCSP Stapling as a directive in HSTS

Tom Ritter <tom@ritter.vg> Mon, 19 January 2015 17:56 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55A1B2B2C for <websec@ietfa.amsl.com>; Mon, 19 Jan 2015 09:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byruQZKj_3YO for <websec@ietfa.amsl.com>; Mon, 19 Jan 2015 09:56:00 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BAC1ACDB2 for <websec@ietf.org>; Mon, 19 Jan 2015 09:56:00 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id hl2so12120611igb.3 for <websec@ietf.org>; Mon, 19 Jan 2015 09:55:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=ObBLKzeX7FHblZZMjhzRarigjmcoU8NxzNG8AWaVFDM=; b=4tYoLUqmcAEQVEy7UzhGC4+62bi2EI69ReCe2LTzQfEL244t/BtDs+mkg1kZmgeINo lzSbW22dlG1yP5EfIw9YsxyorwqY5Y30VWS/nG1BynKU6SZ59EP023oY4bLdonj0nANU HnWTHJ0w3mFtLBfDdDf/1XvoYGSqgVrIYBhgM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ObBLKzeX7FHblZZMjhzRarigjmcoU8NxzNG8AWaVFDM=; b=ftabosZEoOkqsLPnp84b24TdWiDmkUDHnIhETdERdcKXp0A4MfF2e0l4RVVOn+66gc h8YFoCnn3xYh86NjszeSmYJ7BfwuWE4ob7zakpJEJRthb1XFFNh28PerrRNutPuq0jiD 6ordKfP9L4c7Zcmq5WejgTY1XHOKgNA6wpsEEhvarmcvGegANoV5AtrvMNz471lPHjsY b7bGyIG/4L+q8NzTOtUAGMscUtEDAIGjhqYt8ZalBWTPHnTiUK9QTlus7NdeyTsrsNQP XonN/mmyz7KstlWcsQnh8m7dZtZFd9cSEKTnfrnM2Wox1q9juXsIhkNW7qm/1n+kCR8v rxpA==
X-Gm-Message-State: ALoCoQk/jQ1AlIGP1SK7RyoQGKvEIIAMfzdDwLxrE/D3Ygs/q9KAm023ECtqdqMsy30VPEyuBBGl
X-Received: by 10.50.43.229 with SMTP id z5mr20569560igl.19.1421690159414; Mon, 19 Jan 2015 09:55:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.136.209 with HTTP; Mon, 19 Jan 2015 09:55:39 -0800 (PST)
From: Tom Ritter <tom@ritter.vg>
Date: Mon, 19 Jan 2015 11:55:39 -0600
Message-ID: <CA+cU71=LyXAvBYJQdMdmqmtrWg15aUG5tS+VQh9ZLqfHKA4pQw@mail.gmail.com>
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/FfsLW9QmvgSzCF0DoP6gIbkotm8>
Subject: [websec] Requiring OCSP Stapling as a directive in HSTS
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2015 17:56:04 -0000

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