Re: [TLS] OCSP must staple

[Kyle Hamilton <[e-mail]>]

On 6/8/2014 6:51 PM, Salz, Rich wrote:
>> We already have people interested in using must staple upon adoption so this shouldn't be a factor in the adopting the draft.
> That's interesting you have customers interested in I, and that point is as valid as mine saying I don't think our customers will be.  But I didn't say it to forestall adoption of the draft, sorry if I gave you that impression.
>
>> Non-compliance by certain CAs is really irrelevant to whether OCSP Must Staple should be adopted as a standard.
> I didn't say that, either :)  I was just describing what I saw as a bigger issue. And yes, it's completely orthogonal to OCSP; sorry if I wasn't clear.
>
> 	/r$

I've had people tell me that they honestly believe that they're paying
the CA for the OCSP and revocation bandwidth.  This kind of viewpoint
undermines any kind of mandate for any kind of "must staple". 
Personally, I think this view is moderately short-sighted, as it relies
on a third party to be available at all times (particularly with
Firefox's "security.OCSP.require" configuration option).  When I write
protocols I include stapling as par for the course.

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

-Kyle H