Re: [TLS] OCSP must staple

[Kyle Hamilton <[e-mail]>]

On 6/8/2014 10:54 PM, Viktor Dukhovni wrote:
> On Sun, Jun 08, 2014 at 10:44:08PM -0700, Kyle Hamilton wrote:
>
>> On the other hand, I think that relying on a stapled response is perhaps
>> shortsighted, as it potentially opens a window of vulnerability.  Say
>> the OCSP response is valid for 7 days (the maximum time that EV cert
>> OCSP responses can be valid for)
> The CA may well generate new CRLs (and associated OCSP responder
> state) once every 7 days.  Otherwise the OCSP response TTL should
> be shorter, we should address the "right" problem.

My assumption is that a new OCSP response SHALL be generated when the
certificate's status changes, because it is up to the CA to provide
authoritative information about records held by the CA.

In other words, by not generating a new OCSP response when a certificate
is revoked, the CA becomes complicit to any fraud done with that
certificate until the old OCSP response expires.

And, this completely ignores OCSP capacity to request a signature over a
nonce.

> That said there is no "right" upper bound for revocation latency.
> Whatever "acceptable" limit you set, someone will always present
> an argument along the lines of:
>> if the cert is revoked on day 2,
>> that's still 5 and change days of potential validity.  This is the kind
>> of vulnerability that clients can use the OCSP nonce extension to
>> protect themselves from, but it only works if it's used and queried from
>> the OCSP responder by the client itself.  Thus, the proposal to prevent
>> clients from checking OCSP from the source in the presence of an "OCSP
>> must staple" extension is harmful to user security and thus wrong-minded.
> One must be willing to accept some risk, and buy certificates from a
> CA whose OCSP response validity interval poses an acceptable risk.

One must also be able to set the level of risk that they accept.  You're
saying that there is a legal way that this can be taken out of their
hands by the CA or by "common practice".  The specifications appear to
permit a means by which this risk can be short-circuited; however,
you're asserting that "one must be willing to accept some risk", and
thus apparently applying a "MUST NOT attempt to reduce risk beyond the
CA's normally-provided limits" requirement.

> We can debate whether 7 days for EV certs is too long or not, and
> whether it should be adjusted down to 2 days or 2 hours, but the
> fundamental problem remains, and is independent of "must staple".

I used EV certificates only as an example.  (I do believe that 7 days
for EV is "too long", but that's beside the point.)

I do agree that the fundamental problem remains, but the reason I don't
see that it's independent of "must staple" is  in light of your earlier
assertion that "Well, the server was supposed to have stapled, so the
OCSP server could in principle (knowing the server's certificate
requires stapling) refuse to provide an unstapled response." in
explanation of Yoaf Nir's query (paraphrased) "if the client tries the
OCSP server on a must-staple certificate, will the OCSP server reject them?"

Hypothetically speaking, that kind of back-end manipulation of "you can
only have this much assurance" would make me not want to do business
with anyone who insists on doing business with that CA; but, chances are
(particularly for CAs for larger sites) I would quite often be forced
to.  I wish we had a means to present multiple certificate chains
terminating in multiple end-entity certificates of multiple keys, all of
which signed the single key presented and evidenced by the TLS peer. 
That way, any individual CA's policy to limit one's ability to reduce
one's risk would be mitigated by the policies of other CAs that the site
might decide to hire.

But this has now gone far afield from "must staple".

-Kyle H