1

Based on RFC-6960 an OCSP Response should have the following as a minimum:

OCSPResponse ::= SEQUENCE {
  responseStatus         OCSPResponseStatus,
  responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

Here responseStatus can be any one of the following:

OCSPResponseStatus ::= ENUMERATED {
   successful            (0),  -- Response has valid confirmations
   malformedRequest      (1),  -- Illegal confirmation request
   internalError         (2),  -- Internal error in issuer
   tryLater              (3),  -- Try again later
                               -- (4) is not used
   sigRequired           (5),  -- Must sign the request
   unauthorized          (6)   -- Request unauthorized }

Given that OCSP based Certificate Revocation is used in fail-open mode because of the infrastructure reliability issues, does it even make sense to check the responseStatus field at all? Should we just not check it?

I would also appreciate example use cases for this field. How is it being used by people - what are the gains? Performance? Security?

Point to note is that responseStatus field is not a part of the OCSP Response that is signed by the CA (or the responder's certificate) making it vulnerable to tampering. An MITM can potentially tamper this field and alter it to anything but Successful and cause the target client to fail-open.

Another point to note - this can be a DoS candidate for clients configured in fail-close, I am just not considering it in the threat model. The attack I am considering is where the attacker can cause a client to disregard a valid, successful OCSP Response with certificate status REVOKED.

EDIT - My intention is not to suggest to protect the responseStatus field, rather it is to potentially not consider it at all.

1

I understand your concerns, but they unlikely related to your threat model.

An MITM can potentially tamper this field and alter it to anything but Successful and cause the target client to fail-open.

MITM can tamper even signed content and client will reject the response because of invalid signature. Moving response status under signed block -- doesn't prevent from DoS. Thus:

The attack I am considering is where the attacker can cause a client to disregard a valid, successful OCSP Response with certificate status REVOKED.

The result will be the same. OCSP response structure has nothing to do with DoS and can't prevent it in any way.

does it even make sense to check the responseStatus field at all?

I think, it is. Basically, this field says whether there is response body or not. If not, what are potential reasons for empty response body. This is why this field is not authenticated, because response body may be absent.

Like it was already said, MITM can modify any bit in response (authenticated or non-authenticated) and response will become invalid and RevocationOffline message will be returned by OCSP client for this particular request.

To summarize: message signing or encryption doesn't prevent from DoS.

  • As I mentioned in the question itself, I am not concerned about DoS. I am concerned about cases where an attacker can prevent a valid OCSP response from being processed by altering this unprotected field - making this field counterproductive. The problem it causes outweighs its usecase imho and hence the question. – harshc May 15 at 1:07
  • Like I said, an attacker can modify any bit in server response and cause client to reject the response. – Crypt32 May 15 at 4:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.