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

Ryan Sleevi sleevi at google.com
Wed Dec 18 03:01:35 UTC 2013


On Tue, Dec 17, 2013 at 6:41 PM, Wayne Thayer <wthayer at godaddy.com> wrote:

>   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
>

I don't hope to speak for Ben, but my understanding of your question, and
CT's design - whether in it's present form or in the transformed state that
Ben has hinted at - DOES NOT prevent misissuance certificates.

It does, however, provide a global auditable log of all certificates, so
that individual parties can examine for misissuance. Under today's system,
there is no way for the affected site operators to know if a CA has
mis-issued a certificate for their domain - whether through legal means
("compelled CA") or extra-legal means (CA compromise by hackers or
state-level actors). CT closes that hole.

The distinction between the two forms of CT is effectively a distinction of
how much trust is given to these global, auditable logs. The transformed,
"preventative" measure that Ben mentioned is designed to prevent a log from
misleading a relying party. The current system, as implemented within
Chrome and defined in RFC 6962, leaves a small window for a CT log to
mislead relying parties. However, this deception is ALSO auditable and
contains a non-repudiatable proof, which allows for action to be taken
against CT logs that act dishonestly.

There have been, to this date, zero proposals for how to provide a
guaranteed prevention of misissuance. CT accepts this as a nigh-impossible
task - as there are already too many 'soft-knobs' in the Baseline
Requirements and EV guidelines that can't be programatically checked - and
instead seeks to provide a guaranteed detection mechanism for the public -
both the site operators and parties interested in the SSL/TLS PKI ecosystem.

Does that clarify things?




For those who want the gory details, the current SignedCertificateTimestamp
design is, in effect, a cryptographic promise by the CT log that it will
log the given certificate and make those details available via the RFC 6962
API at a point in the future. A client can, at any point, check to see if
the promise has been fulfilled. A client that checks these SCTs can enforce
a Maximum Merge Delay (Section 3 / Section 5 of RFC 6962), which if the SCT
is not integrated by the MMD, it knows the log has failed it's promise. A
client does not necessarily need to check each SCT immediately after the
MMD has expired - it could, for example, defer this to a later point as a
general "the system is working well", and only alert for any SCTs that
hadn't been integrated by the MMD.

A maliciously behaving log would issue SCTs, but then fail to incorporate
them within the CT log, thus preventing the public (and auditors) from
being aware of the fact that these certificates were issued. However,
because every CT-validating client will expect to receive an SCT, they will
have cryptographic proof of the logs dishonesty - and can then take action
against the log, without necessarily taking action against the CA.
Detecting log dishonesty is handled through Section 5 of RFC 6962.

One possible way that CT can be 'retooled' to be stricter - but which
induces additional delays into the issuance pipeline - is to embed the
proof of presence within the log, rather than the promise of presence
within the log. However, this requires a delay from the time a CA submits a
certificate to the log to when the log reaches it's eventually-consistent
state and provides that proof of presence.

It offers a much stronger guarantee of the log's honesty to clients and
auditors, but the increased issuance delay (effectively, the Maximum Merge
Delay of the Log) was too much for some CAs to feel comfortable.


>
>    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>
>  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', 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] On Behalf Of Wayne Thayer
>> > Sent: Tuesday, December 17, 2013 8:50 AM
>> > To: Ben Laurie
>> > Cc: 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] On Behalf Of Ben Laurie
>> > Sent: Tuesday, December 17, 2013 5:29 AM
>> > To: Rick Andrews
>> > Cc: 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
>> > https://cabforum.org/mailman/listinfo/management
>> _______________________________________________
>> Management mailing list
>> 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>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', 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] On Behalf Of Wayne Thayer
>> > Sent: Tuesday, December 17, 2013 8:50 AM
>> > To: Ben Laurie
>> > Cc: 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] On Behalf Of Ben Laurie
>> > Sent: Tuesday, December 17, 2013 5:29 AM
>> > To: Rick Andrews
>> > Cc: 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
>> > https://cabforum.org/mailman/listinfo/management
>> _______________________________________________
>> Management mailing list
>> 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/20131217/a1c2449c/attachment-0003.html>


More information about the Public mailing list