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

[Sigbjørn Vik]

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