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

[Jeremy Rowley]

-----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 9: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?

- Then the log becomes untrusted.  Either it gossips or it's not trusted.
Of course, all the government needs to do is coerce the browser to trust a
non-public log and you have the same effect. You are worrying about an
attack where easier work-arounds exist for government entities.   

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

- I don't necessarily agree.  The reliability of the logs is equally as
important.  A log going down is a serious event.  If two logs go down, and
they are the same two logs the CA is using, then there is a major problem.
I'd rather trust a log run by someone with multi-national presence (and thus
subject to the jurisdiction of several areas) that a small log operator who
may be untrusted later on.

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

- Then the log is not trusted.

> A CA's log that is offline too long becomes untrusted.

And if a 30 second window is all it takes?

- This is starting to smell like FUD.  What if the government demands the
browser not list their log as publicly trusted?

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

- Neither does the proposal to require mutli-jurisdictional logs, especially
since the only two logs (that I know of) are Google and DigiCert, both
located jurisdictionally in the US.

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.

- Okay.  But that isn't stopped with mulit-jurisdictional logs. 

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?

- As much as I trust every browser employee to do the same thing when
presented with the same scenario.

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?

- There are rules protecting against this.  Whether they are sufficient is
the question.  I propose the are, at least for phase 1.

This fix is easy, don't set up a system which allows governments (or
individual CAs) to do this.

- Okay.  How?  Multi-jurisdictional logs don't do that.  All you've done is
make the browsers the target, which is already more likely than the CA.

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