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

Tue Dec 17 20:11:40 UTC 2013

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/1be125dc/attachment-0002.html>