[cabfpub] Upcoming changes to Google Chrome's certificate handling

Ben Laurie benl at google.com
Tue Nov 12 10:58:51 UTC 2013

On 11 November 2013 19:29, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> Could some of these concerns be addressed by a reworking of the roles in CT?
> It seems to me that the entity with the most concern about mis-issuance and the trustworthiness of the logs is the domain/web site owner. Each domain/web site owner could run their own log, instead of the logs being global in nature and potentially open to government or other tampering. That greatly minimizes the size of the log and the performance requirements for it. Plus it keeps the log private to the domain owner. No one else can obtain a list of all certs issued for the domain. The domain owner becomes the monitor for its domain; no external monitor is needed. I would imagine that it could be deployed as a web server with minimal networking and memory needs.
> It also allows CT to be deployed only by those customers who saw the value in it. They would have to signal the requirement, probably by some record in their DNS zone file, that would give a pointer to their log server.
> A CA wishing to issue a cert for that domain would check DNS, see that the domain owner required CT, and send the pre-certificate to that log server. Only one SCT is needed, because presumably the domain owner trusts its own log and it's highly unlikely that the log would become untrusted.
> The browsers would still have to be the policemen. When visiting a site, they'd have to check DNS to see if the customer required CT, and if so, they would expect to find an SCT in the certificate. The log's public key would also have to be in DNS, so that the browser could verify the signature on it. Obviously this requires DNSSEC and I imagine some people will think that's enough to kill the idea, but I don't.
> The main idea is that if a domain owner wants to use CT, it forces each CA that wants to issue a cert for the domain to register the issuance directly with the domain owner. That's more direct than having the CA register with some number of external logs and then relying on someone else to monitor all those logs to find certs issued for a particular domain, and then tell the domain owner which certificates it found.
> This needs more thought, but it seems to address many of our concerns about CT.

The most obvious problem with this idea (which I kinda like in theory)
is that it relies on DNSSEC, which

a) Has the same security issue that CT is designed to address, so we'd
have to first deploy DNSSEC Transparency (something we intend to work
on, BTW),

b) Doesn't work a lot of the time.

That said, if we had a truly solid DNSSEC deployment, there are lots
of potential DNSSEC-based solutions.

Another issue is that Chrome rules out any out-of-band signalling, so
there would have to be DNSSEC stapling, or some similar mechanism.

> -Rick
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Sigbjørn Vik
>> Sent: Friday, November 08, 2013 8:25 AM
>> To: Jeremy Rowley; public at cabforum.org
>> Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate
>> handling
>> On 08-Nov-13 16:10, Jeremy Rowley wrote:
>> > I disagree.  For the outset, the log operator responsibility has been
>> to
>> > gossip with other logs to ensure they aren't forked or in a bubble.
>> And if forced by threat to do otherwise by the government?
>> > The
>> > CA's responsibility is to log the certificate in a trusted log.  The
>> browser
>> > is responsible for determining the trustworthiness of the log.  Each
>> actor
>> > has a role to play.
>> I am saying that the trustworthiness of a separate log is greater than
>> that of a log made by the same people who issued the CA, as collusion
>> is
>> less likely.
>> > A log proof from the CA itself should be sufficient as the logs are
>> supposed
>> > to communicate with each other.
>> Unless forced not to, e.g. by government.
>> > A CA's log that is offline too long becomes
>> > untrusted.
>> And if a 30 second window is all it takes?
>> > Plus, I trust DigiCert's log server availability and integrity
>> > way more than I trust anyone else's.  If I'm hitting a couple of log
>> > servers, I want them to be the servers I know won't go down or be
>> untrusted.
>> Let me explain the attack scenario in more detail. None of the
>> protections you mention above can protect against this, even if
>> implemented strictly and correctly.
>> Some government agency acquires a cert and a forked log proving its
>> authenticity. They hijack some victim's internet connection. They let
>> the victim's browser gossip as much as it likes. Once the victim visits
>> their mail account, gossip protocols are shut down, and they serve the
>> false certificate and the log proof, thus obtaining the user's
>> password.
>> Once the password is obtained, the SWAT team swoops in and confiscates
>> the computer, wiping the traces of the forged certificate and proof.
>> Unless the browser is going to stop the login because of a 30 second
>> gossipless window, this would work just fine.
>> Do you trust every employee at DigiTrust to do the right thing when
>> presented a threat of 10 years in jail (or worse) unless they fork over
>> some documents to the government and do not ever mention it to anyone?
>> And even if you do, do you trust every employee of every CA in every
>> country to do the same, or would you rather have rules protecting
>> against this?
>> This fix is easy, don't set up a system which allows governments (or
>> individual CAs) to do this.
>> > -----Original Message-----
>> > From: public-bounces at cabforum.org [mailto:public-
>> bounces at cabforum.org] On
>> > Behalf Of Sigbjørn Vik
>> > Sent: Friday, November 08, 2013 3:01 AM
>> > To: public at cabforum.org
>> > Subject: Re: [cabfpub] Upcoming changes to Google Chrome's
>> certificate
>> > handling
>> >
>> > On 07-Nov-13 20:44, Jeremy Rowley wrote:
>> >
>> >> 5)      Size. We do not support Google's recommendation for three
>> >> separate time stamps.  Two is sufficient to provide protection.  In
>> >> fact, I'd prefer to include only a single proof in each certificate.
>> >> If you log a cert to multiple servers, you can include a new proof
>> >> later on during re-issue, which minimizes concerns about log
>> compromise.
>> >> Regardless, I do not think Google should dictate the number of logs.
>> >> Instead, each CA should individually evaluate the risks of a log
>> >> compromise or unavailability and decide the number of proofs
>> required.
>> >
>> > There is an additional requirement I would like to see implemented on
>> the
>> > proofs, that at least one is issued by a log under a different
>> jurisdiction
>> > than the certificate. The threat scenario is a government agency
>> telling CAs
>> > "We want a certificate for this site and a forked log proving it.",
>> then
>> > deploying this in a closed network from where it will never leak.
>> >
>> > A log proof from the CA itself should never be considered sufficient,
>> as
>> > this makes authoritarian misconduct much easier. A requirement for
>> different
>> > jurisdictions would also make life easier for CAs, as they don't have
>> to
>> > worry about government interference.
>> >
>> > --
>> > Sigbjørn Vik
>> > Opera Software
>> > _______________________________________________
>> > Public mailing list
>> > Public at cabforum.org
>> > https://cabforum.org/mailman/listinfo/public
>> >
>> --
>> Sigbjørn Vik
>> Opera Software
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

More information about the Public mailing list