[cabfpub] [cabfman] Improving the security of EV Certificates

[Wayne Thayer]

Ryan – thanks for the detailed response you’ve provided below.  You’ve presented a great case for why CT is important, and I agree with all of your points, yet they still leaves me with the sense that CT – even in the transformed state that Ben mentioned – won’t prevent a certificate from being mis-issued and used maliciously, at least for a while.  It might be a short while in the case of a bad certificate when the company has tight central control over cert approvals, an automated log monitoring/alerting system, and a clear understanding of how to respond to the incident.  It might be a very long while if any of these conditions isn’t met.  Is that what’s implied when Ben says that CT could be transformed into a “preventative” system, or am I still missing something?

Wayne

Moving this to the public list, with Wayne and Rick's consent.


On Tue, Dec 17, 2013 at 10:41 AM, Wayne Thayer <wthayer at godaddy.com<mailto:wthayer at godaddy.com>> wrote:
>Wayne, I think what Ben means is that CT can be tuned to be "preventative"
>
if CAs would be willing to withhold a certificate from the customer until
>monitors and auditors have had a chance to see it and agree that it was
>properly issued.

Yes, that's my understanding.  But what does it mean for a monitor to agree that a cert was properly - or more importantly to agree a cert was improperly - issued?  And what do they do about it?  For instance, if a small European CA issues a cert for 'www.eu.bankofamerica.com<http://www.eu.bankofamerica.com/>', how does anyone other than B of A know if it's mis-issued?  How long will it take for them to figure it out?  And how long will it take to distrust/revoke the cert once all of this is established?

I think it's important to compare with today's scheme, which is there is no means of detecting. CT works at present as a "detect-only" - it does not serve to revoke improperly issued certificates, nor does it seek to provide an additional check to prevent improper certificates from being issued.


Who can evaluate whether a certificate is bad:

To answer your question directly, on a formal level, only BoA - or anyone it has contracted with (ala MarkMonitor or any open monitor DBs that may rise) - can evaluate whether or not that certificate was authorized. Alternatively, if they published policy information (perhaps in machine readable form, like CAA or HPKP), it might be possible for monitors to flag it as potentially misissued. This is no different than the existing flows today - only the customer is capable of determining whether or not it's authorized. They can outsource this authorization check to competent third parties, but in the end, they're the only ones who know what they're doing or have done.


How long does it take for them to figure out out:

If the certificate is logged in CT, it takes up to the maximum merge delay of the log for it to be visible within the log, and then however long it takes monitors to query the log for updates and evaluate.
If the certificate is not logged in CT, then it behaves like our existing system for detection (ie: there is none).
Chrome's push to require CT for EV certificates, with the eventual goal of requiring for all certificates, acts as a forcing function to get a certificate logged. If a certificate is not logged, it's no different than any other self-signed or distrusted certificate, and the risk to users is the same. By having all certificates logged, we reduce the detection from "The time someone wonders about this weird thing they saw this one time" to something that can be programatically done (mod the issue I discuss below about log dishonesty)


How long does it take to distrust/revoke the certificate:

CT does not change the revocation flow at all. Presumably this small European CA will update its CRLs and OCSP responders to revoke the certificate according to their CPS. In practice, I'm sure one of these small European CAs will have forgotten to configure a CRL or OCSP responder URL, or will have set it to be so laughably bad (eg: nextUpdate 3 years in the future) that it will require a more reactive response of user agents, such as MSFT's Certificate (Dis)trust List, Chrome's CRLSets, or Firefox's not-yet-implemented-but-similar-to-the-above-two methods (or through blacklisting + Firefox security update)

Still, under today's world, no one will ever notice or cause this certificate to be revoked, unless/until it happens to be picked up by some scan such as those by the EFF SSL Observatory or Netcraft and is suspicious enough for someone to blog post about it. (Mandatory) CT closes this detection gap.


>If CAs have pushed back on this, it's probably because customers would push
>back on us. We've probably all had customers who need a certificate 10 minutes
>ago because they missed their cert's expiration and they're running with an expired cert.
>
>I have no idea what's a reasonable time period for monitors and auditors to satisfy
>themselves that a newly-issued cert was intentional or mis-issued. Each customer
>who cared would probably have to make some human available 24x7 to respond to
>alerts from monitors.

That fits my understanding, and is why I question how CT can be transformed to a "preventative" mode.

In the current implementation of CT, there is ample opportunity for the log to be dishonest. While this can be eventually detected (through clients gossipping or sharing observed CT proofs), and alternative scheme for CT would embed much stronger certificate proofs into the certificate, so that any dishonesty can be (nearly immediately) detected. However, in order to get to that stronger guarantee against log dishonesty, it would require certificates be held from issuance until the log was in a consistent state.

The current form of CT is very much akin to the notion of public audits of CA's issuance practices. This may not seem like a 'strong' security guarantee, because CAs can still "cook the books", it at least increases the risk that any CA who does or is cooking the books will get detected.

Additionally, we have seen with the past several multi-vendor security incidents, CAs are still having trouble detecting their own misissuances and adhering to their stated CPSes. CT helps CAs makes this easier, by crowd-sourcing their audits. As long as there is nothing to hide, there's no risk, but significant public benefit.


By the way, none of this changes my belief that CT is a useful detection mechanism.

>
>-Rick

> -----Original Message-----
> From: management-bounces at cabforum.org<mailto:management-bounces at cabforum.org> [mailto:management-<mailto:management->
> bounces at cabforum.org<mailto:bounces at cabforum.org>] On Behalf Of Wayne Thayer
> Sent: Tuesday, December 17, 2013 8:50 AM
> To: Ben Laurie
> Cc: management at cabforum.org<mailto:management at cabforum.org>
> Subject: Re: [cabfman] Improving the security of EV Certificates
>
> Ben - with the following statement, you've touched on a part of CT
> that I don't think I fully understand:
>
> It is worth noting that CT has various tunable parameters which can
> transform it from "detect after the fact" to "preventative", but CAs
> have already objected to tuning in that direction. To be clear, to
> turn CT into a fully preventative system, all that is needed is for
> the certificate to not be valid until the log has sequenced it and
> monitors have acknowledged they have seen it.
>
> In my mind a perfect "preventative" solution would cause the
> certificate to stop working prior to being relied on by anyone.  A
> good "preventative" solution would work like pinning where a large
> percentage of site visitors should be protected.  I understand that CT
> could allow monitors to see a mis-issued cert prior to first use, but
> I don't understand how that in turn prevents the cert from being
> relied upon?  I assume that Google will be monitoring their domains,
> but who will monitor (for instance) all the banking domains?  And once
> a bad certificate is found, how is that cert disabled/revoked?  CRL Sets?
> I'm trying to understand how long it will take to confirm that a
> "typical" cert has been mis-issued and how long it will take to
> disable it.  By "typical", I mean one where the legitimate domain
> owner isn't actively monitoring a number of CT logs.
>
> Thanks,
>
> Wayne
>
> -----Original Message-----
> From: management-bounces at cabforum.org<mailto:management-bounces at cabforum.org> [mailto:management-<mailto:management->
> bounces at cabforum.org<mailto:bounces at cabforum.org>] On Behalf Of Ben Laurie
> Sent: Tuesday, December 17, 2013 5:29 AM
> To: Rick Andrews
> Cc: management at cabforum.org<mailto:management at cabforum.org>
> Subject: Re: [cabfman] Improving the security of EV Certificates
>
> It has been brought to my attention that I somehow neglected to
> respond to this.
>
> Apologies for the delay.
>
> _______________________________________________
> Management mailing list
> Management at cabforum.org<mailto:Management at cabforum.org>
> https://cabforum.org/mailman/listinfo/management
_______________________________________________
Management mailing list
Management at cabforum.org<mailto:Management at cabforum.org>
https://cabforum.org/mailman/listinfo/management



On Tue, Dec 17, 2013 at 10:41 AM, Wayne Thayer <wthayer at godaddy.com<mailto:wthayer at godaddy.com>> wrote:
>Wayne, I think what Ben means is that CT can be tuned to be "preventative"
>
if CAs would be willing to withhold a certificate from the customer until
>monitors and auditors have had a chance to see it and agree that it was
>properly issued.

Yes, that's my understanding.  But what does it mean for a monitor to agree that a cert was properly - or more importantly to agree a cert was improperly - issued?  And what do they do about it?  For instance, if a small European CA issues a cert for 'www.eu.bankofamerica.com<http://www.eu.bankofamerica.com>', how does anyone other than B of A know if it's mis-issued?  How long will it take for them to figure it out?  And how long will it take to distrust/revoke the cert once all of this is established?

>If CAs have pushed back on this, it's probably because customers would push
>back on us. We've probably all had customers who need a certificate 10 minutes
>ago because they missed their cert's expiration and they're running with an expired cert.
>
>I have no idea what's a reasonable time period for monitors and auditors to satisfy
>themselves that a newly-issued cert was intentional or mis-issued. Each customer
>who cared would probably have to make some human available 24x7 to respond to
>alerts from monitors.

That fits my understanding, and is why I question how CT can be transformed to a "preventative" mode.

By the way, none of this changes my belief that CT is a useful detection mechanism.

>
>-Rick

> -----Original Message-----
> From: management-bounces at cabforum.org<mailto:management-bounces at cabforum.org> [mailto:management-<mailto:management->
> bounces at cabforum.org<mailto:bounces at cabforum.org>] On Behalf Of Wayne Thayer
> Sent: Tuesday, December 17, 2013 8:50 AM
> To: Ben Laurie
> Cc: management at cabforum.org<mailto:management at cabforum.org>
> Subject: Re: [cabfman] Improving the security of EV Certificates
>
> Ben - with the following statement, you've touched on a part of CT
> that I don't think I fully understand:
>
> It is worth noting that CT has various tunable parameters which can
> transform it from "detect after the fact" to "preventative", but CAs
> have already objected to tuning in that direction. To be clear, to
> turn CT into a fully preventative system, all that is needed is for
> the certificate to not be valid until the log has sequenced it and
> monitors have acknowledged they have seen it.
>
> In my mind a perfect "preventative" solution would cause the
> certificate to stop working prior to being relied on by anyone.  A
> good "preventative" solution would work like pinning where a large
> percentage of site visitors should be protected.  I understand that CT
> could allow monitors to see a mis-issued cert prior to first use, but
> I don't understand how that in turn prevents the cert from being
> relied upon?  I assume that Google will be monitoring their domains,
> but who will monitor (for instance) all the banking domains?  And once
> a bad certificate is found, how is that cert disabled/revoked?  CRL Sets?
> I'm trying to understand how long it will take to confirm that a
> "typical" cert has been mis-issued and how long it will take to
> disable it.  By "typical", I mean one where the legitimate domain
> owner isn't actively monitoring a number of CT logs.
>
> Thanks,
>
> Wayne
>
> -----Original Message-----
> From: management-bounces at cabforum.org<mailto:management-bounces at cabforum.org> [mailto:management-<mailto:management->
> bounces at cabforum.org<mailto:bounces at cabforum.org>] On Behalf Of Ben Laurie
> Sent: Tuesday, December 17, 2013 5:29 AM
> To: Rick Andrews
> Cc: management at cabforum.org<mailto:management at cabforum.org>
> Subject: Re: [cabfman] Improving the security of EV Certificates
>
> It has been brought to my attention that I somehow neglected to
> respond to this.
>
> Apologies for the delay.
>
> _______________________________________________
> Management mailing list
> Management at cabforum.org<mailto:Management at cabforum.org>
> https://cabforum.org/mailman/listinfo/management
_______________________________________________
Management mailing list
Management at cabforum.org<mailto:Management at cabforum.org>
https://cabforum.org/mailman/listinfo/management

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131218/8a384ef8/attachment-0003.html>