Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

From: Santosh Chokhani <[email-masked]>
Date: Sat, 3 Nov 2012 19:25:48 -0400

I agree with Liaquat.

I would emphasize that CA products have magical controls to protect once compromised is not supported by the analysis of some of the commonly used CA products.

To think that OCSP certificate is somewhat special and hard to mint is an error.

Even a CA certificate can be easily minted from a CA once a CA is compromised.  The only saving grace here may be the parent CA had path length = 0 in the compromised CA certificate protecting relying parties from accepting a minted CA certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Liaquat Khan
Sent: Saturday, November 03, 2012 6:48 PM
To: Yngve N. Pettersen (Developer Opera Software ASA); [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

IMO an attacker that has the capability to bypass the normal CA security controls and access the CA's private signing key to issue fake certificates will be capable of also generating fake OCSP responder certificates.  

The fact that OCSP responder certificates contain special extension (I assume you were referring to EKU extension) is hardly going to raise the bar in terms of complexity for the attacker.  Security should not hinge on the fact that the attacker cannot add an extension in the to-be-signed certificate, since this is just manipulating the input to the certificate signing process, but rather that they cannot use the CA's private signing key. So IMO if they can issue one fake certificate without detection, it's safer to assume they can issue multiple certificates and also of different types. 

In some cases you may be right, but to make a general statement that it's much harder to issue an OCSP certificate compared to an end-entity certificate is indeed a "false sense of security".

On 03/11/2012 21:08, "Yngve N. Pettersen (Developer Opera Software ASA)"
<[email-masked]> wrote:

>On Sat, 03 Nov 2012 21:17:02 +0100, Santosh Chokhani 
><[email-masked]> wrote:
>
>> The attacker can mint a delegated OCSP Responder certificate and 
>> browsers will not know of it.
>
>AFAIK delegated OCSP certificates require special attributes, meaning 
>that the attacker would need to be able to access a system that could 
>issue such a certificate.
>
>If the CA system allows any extension to be set, or the CA system 
>issuing
> 
>OCSP responder certs can be compromised then, yes, an OCSP minting cert 
>could be created and arbitrary responses created, as would be possible 
>if
> 
>the attacker managed to take control over the OCSP system itself. If an 
>OCSP minting cert is created, then the only way to repair the problem 
>is to revoke the issuing subCA. The same would be the case if the 
>certificate issuance system allowed arbitrary byte sequences, e.g.  an 
>OCSP response,
> 
>to be signed.
>
>That is, however, part of what I mention about the attacker requiring 
>deeper penetration than just what is needed to issue certs, increasing 
>the risk of detection. It is up to the CA to design their system so 
>that such
> 
>special certificates cannot be created without the CA intending to do so.
>
>In my opinion, an issuing system should not be able to set arbitrary 
>extensions, they should be part of what the CA have hardcoded for that 
>particular product.
>
>In part, these changes are made to eliminate a direct security problem 
>(and I do say they are not a panacea) and, like many security measures, 
>in part to increase the hassle and risks for the attacker by making an 
>"easy"
>attack less feasible. In other ongoing work, other aspects of the 
>attack is being countered, also seeking to block an attack, or increase 
>the risks for the attacker.
>
>
>
>--
>Sincerely,
>Yngve N. Pettersen
>********************************************************************
>Senior Developer		     Email: [email-masked]
>Opera Software ASA                   http://www.opera.com/
>Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
>********************************************************************
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix
>

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Ryan Sleevi" <[email-masked]>
Date: Sat, 3 Nov 2012 17:33:08 -0700

To assume that an RA compromise + logging denial of service, for sake of
example, is the same as allowing arbitrary signing access, is equally an
error.

I agree with Yngve - this is not trying, nor claiming to try, to resolve
all the security issues involved with CA compromise. But it does raise the
bar for security, by making it *possible* for CAs to make it more
difficult for attackers to evade detection *in some situations*. And in
practice, once something is possible for CAs to do something that improves
overall security, it's near guaranteed that the browser and root store
operators will *require* the CAs to do so posthaste.

The point here is that CA systems frequently involve multiple layers of
communication between different systems, with different access controls
and audit schemes. It's hardly an informed comment to suggest that the
ability to compromise a single issuance workflow is equivalent to
arbitrary access to the key material or that it is equal to a signing
oracle, no matter how compelling it is to think about it in the
hypothetical.

Does the proposal defend against signing oracles or arbitrary key material
access? No, as Yngve has repeated and which should hopefully be obvious.
But I support Yngve's assertion that this does provide some degree of
benefit for at least some situations, and even if that benefit is merely
that an attacker must "work harder," that's a meaningful benefit to both
the public CAs participating in the so-called "web PKI" and to the
browsers and relying party software that are collectively used by hundreds
of millions of users on the Internet today.

On Sat, November 3, 2012 4:25 pm, Santosh Chokhani wrote:
>  I agree with Liaquat.
>
>  I would emphasize that CA products have magical controls to protect once
>  compromised is not supported by the analysis of some of the commonly used
>  CA products.
>
>  Even a CA certificate can be easily minted from a CA once a CA is
>  compromised.  The only saving grace here may be the parent CA had path
>  length = 0 in the compromised CA certificate protecting relying parties
>  from accepting a minted CA certificate.
>
>  IMO an attacker that has the capability to bypass the normal CA security
>  controls and access the CA's private signing key to issue fake
>  certificates will be capable of also generating fake OCSP responder
>  certificates.
>
>  The fact that OCSP responder certificates contain special extension (I
>  assume you were referring to EKU extension) is hardly going to raise the
>  bar in terms of complexity for the attacker.  Security should not hinge on
>  the fact that the attacker cannot add an extension in the to-be-signed
>  certificate, since this is just manipulating the input to the certificate
>  signing process, but rather that they cannot use the CA's private signing
>  key. So IMO if they can issue one fake certificate without detection, it's
>  safer to assume they can issue multiple certificates and also of different
>  types.
>
>  In some cases you may be right, but to make a general statement that it's
>  much harder to issue an OCSP certificate compared to an end-entity
>  certificate is indeed a "false sense of security".
>
>

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 3 Nov 2012 20:43:40 -0400

Ryan,

There is a hell of difference between claims "does provide some degree of benefit" and "provides an extra layer of security".  Decide which one you want to claim.

Also, DigiNotar attack was a CA compromise and not an RA.

You are doing disservice to the readers by confusing the issues.

I have no idea if you yourself are confused or doing this intentionally and if so for what purpose.

-----Original Message-----
From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Saturday, November 03, 2012 8:33 PM
To: Santosh Chokhani
Cc: Liaquat Khan; Yngve N. Pettersen (Developer Opera Software ASA); [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

To assume that an RA compromise + logging denial of service, for sake of example, is the same as allowing arbitrary signing access, is equally an error.

I agree with Yngve - this is not trying, nor claiming to try, to resolve all the security issues involved with CA compromise. But it does raise the bar for security, by making it *possible* for CAs to make it more difficult for attackers to evade detection *in some situations*. And in practice, once something is possible for CAs to do something that improves overall security, it's near guaranteed that the browser and root store operators will *require* the CAs to do so posthaste.

The point here is that CA systems frequently involve multiple layers of communication between different systems, with different access controls and audit schemes. It's hardly an informed comment to suggest that the ability to compromise a single issuance workflow is equivalent to arbitrary access to the key material or that it is equal to a signing oracle, no matter how compelling it is to think about it in the hypothetical.

Does the proposal defend against signing oracles or arbitrary key material access? No, as Yngve has repeated and which should hopefully be obvious.
But I support Yngve's assertion that this does provide some degree of benefit for at least some situations, and even if that benefit is merely that an attacker must "work harder," that's a meaningful benefit to both the public CAs participating in the so-called "web PKI" and to the browsers and relying party software that are collectively used by hundreds of millions of users on the Internet today.

On Sat, November 3, 2012 4:25 pm, Santosh Chokhani wrote:
>  I agree with Liaquat.
>
>  I would emphasize that CA products have magical controls to protect 
> once  compromised is not supported by the analysis of some of the 
> commonly used  CA products.
>
> length = 0 in the compromised CA certificate protecting relying 
> parties  from accepting a minted CA certificate.
>
>  IMO an attacker that has the capability to bypass the normal CA 
> security  controls and access the CA's private signing key to issue 
> fake  certificates will be capable of also generating fake OCSP 
> responder  certificates.
>
>  The fact that OCSP responder certificates contain special extension 
> (I  assume you were referring to EKU extension) is hardly going to 
> raise the  bar in terms of complexity for the attacker.  Security 
> should not hinge on  the fact that the attacker cannot add an 
> extension in the to-be-signed  certificate, since this is just 
> manipulating the input to the certificate  signing process, but rather 
> that they cannot use the CA's private signing  key. So IMO if they can 
> issue one fake certificate without detection, it's  safer to assume 
> they can issue multiple certificates and also of different  types.
>
>  In some cases you may be right, but to make a general statement that 
> it's  much harder to issue an OCSP certificate compared to an 
> end-entity  certificate is indeed a "false sense of security".
>
>
> >OCSP responder certs can be compromised then, yes, an OCSP minting 
> >cert could be created and arbitrary responses created, as would be 
> >possible if
> >
> >the attacker managed to take control over the OCSP system itself. If 
> >an OCSP minting cert is created, then the only way to repair the 
> >problem is to revoke the issuing subCA. The same would be the case if 
> >the certificate issuance system allowed arbitrary byte sequences, 
> >e.g.  an OCSP response,
> >
> >to be signed.
> >
> >deeper penetration than just what is needed to issue certs, 
> >increasing the risk of detection. It is up to the CA to design their 
> >system so that such
> >
> >extensions, they should be part of what the CA have hardcoded for 
> >that particular product.
> >
> >In part, these changes are made to eliminate a direct security 
> >problem (and I do say they are not a panacea) and, like many security 
> >measures, in part to increase the hassle and risks for the attacker 
> >by making an "easy"
> >attack is being countered, also seeking to block an attack, or 
> >increase the risks for the attacker.
> >
> >
> >
> >--
> >Sincerely,
> >Yngve N. Pettersen

---

From: "Piyush Jain" <[email-masked]>
Date: Sat, 3 Nov 2012 18:16:24 -0700

Thanks Santosh and Liaquat.
That has been my biggest objection to adding the new text to OCSP - it
creates a false sense of security.

Ygnve I appreciate you analysis of the DigiiNotor incidence. However, I
still believe that the changes proposed here or in the CAB forum won't have
helped and attacker would have been able to circumvent any additional
measures that were put in place based on these proposals.

Please note that based on current text in OCSP, the responder can return
unknown or INTERNAL ERROR for such certificates. In my opinion, changing the
standards to accommodate clients who are not updated is never good. CAs can
always decide to return revoked for fraudulently issued certificates for
some period of time, until all clients are updated to Opera like
functionality to reject access if certificate status is unknown.
Another alternative could be to create a profile of OCSP for webPKI  that
adds recommendations which make sense for webPKI.

-Piyush

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Santosh Chokhani
> Sent: Saturday, November 03, 2012 4:26 PM
> To: Liaquat Khan; Yngve N. Pettersen (Developer Opera Software ASA);
> [email-masked]
> compromised is not supported by the analysis of some of the commonly
> used CA products.
> 
from
> accepting a minted CA certificate.
> 
certificates will
> be capable of also generating fake OCSP responder certificates.
> 
assume
> you were referring to EKU extension) is hardly going to raise the bar in
terms
> of complexity for the attacker.  Security should not hinge on the fact
that the
> attacker cannot add an extension in the to-be-signed certificate, since
this is
> just manipulating the input to the certificate signing process, but rather
that
> they cannot use the CA's private signing key. So IMO if they can issue one
> fake certificate without detection, it's safer to assume they can issue
multiple
> certificates and also of different types.
>

---

From: [email-masked] (Martin Rex)
Date: Mon, 5 Nov 2012 15:15:59 +0100 (CET)

> To think that OCSP certificate is somewhat special and hard to mint

This is why an updated OCSP spec should not allow the EE signing key
to issue OCSP signer certs.

Existing OCSP and existing CRL are broken by _design_, not by implementation,
so without updating the spec to provide additional protection and without
updating the installed base to use it, there is not going to be any
improvement.

> compromised.  The only saving grace here may be the parent CA had
> path length = 0 in the compromised CA certificate protecting relying

I doubt that path length = 0 helps.

Self-issued certs are specified to not count for the path len,
so the CA cert that the attacker has to create is one where
subject=issuer, i.e a self-issued CA cert.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 5 Nov 2012 11:00:05 -0500

On the OCSP Certificate Signer, we are where we are,  Unless you provide a total solution, the security and software complexity comparison cannot be made.

Your point about self-issued is well taken.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, November 05, 2012 9:16 AM
To: Santosh Chokhani
Cc: Liaquat Khan; Yngve N. Pettersen (Developer Opera Software ASA); [email-masked]
Subject: Re: [pkix] What's the need to introduce fraudulently issued certificates in OCSP

> To think that OCSP certificate is somewhat special and hard to mint is 

This is why an updated OCSP spec should not allow the EE signing key to issue OCSP signer certs.

Existing OCSP and existing CRL are broken by _design_, not by implementation, so without updating the spec to provide additional protection and without updating the installed base to use it, there is not going to be any improvement.

Self-issued certs are specified to not count for the path len, so the CA cert that the attacker has to create is one where subject=issuer, i.e a self-issued CA cert.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 5 Nov 2012 08:17:26 -0800

> This is why an updated OCSP spec should not allow the EE signing key to
issue
> OCSP signer certs.
> 
> Existing OCSP and existing CRL are broken by _design_, not by
> implementation, so without updating the spec to provide additional
> protection and without updating the installed base to use it, there is not
> going to be any improvement.
> 
[Piyush] To claim that OCSP and CRLs are broken is stretch. Both do exactly
what they are supposed to do - tell you if a certificate is revoked by the
issuing authority. If you really believe that OCSP and CRL are broken and
should go through wholesale changes, isn't it better to address the issue by
creating a new protocol that addresses these issue, instead of affecting all
the deployments that still wish to use OCSP and CRLs in the traditional way?

I understand that you would like these specifications to do more to avoid
revoking the CA even when it is compromised and make OCSP and CRLs more
authoritative that the CA. As I said before, nothing wrong with the idea -
many systems utilize user databases to authenticate a user. PKC is used as
alternative to such systems because it addresses lot of operational problems
associated with such systems. White lists are difficult to transport,
especially in cases where the user population is huge. A single system which
checks for validity becomes performance bottleneck and to replicate the
information across geographies to address scalability imposes security and
logistical problems.

Is the cost of additional protection that you allude to, justified? Most
people would say yes to more security, but will question the benefit if you
lay out the cost associated with providing that security. Unfortunately, the
proponents of the changes to OCSP have cited reasons ranging from - "it
makes it more difficult for attacker" to it adds "additional layer of
security" without providing any concrete analysis of scenarios that
substantiates these claims. 
> Self-issued certs are specified to not count for the path len, so the CA
cert
> that the attacker has to create is one where subject=issuer, i.e a
self-issued
> CA cert.
[Piyush] I agree. And it is all the more reason to be skeptical about the
benefits of addressing fraudulently issued certificates through OCSP.