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

[kirk_hall at trendmicro.com]

Rick, this is a very intriguing suggestion.  While I'm not as competent as others on this list concerning the technical requirements of CT, I have felt that CT is a very big solution to a problem faced by only a limited number of (very important) domains and website owners.   

If there were some elegant way to get the benefits of CT for the high-risk target domains without pulling in every other domain to the same system, and giving the owners of the target domains the choice and control over their own implementation of CT for their domains (with cooperation from the CAs as you suggest), that seems like a very good idea.

Can we keep working on this alternative to see if it is faster, cheaper, and just as effective as Classic CT?  We might be able to get to implementation for the high-risk target domains much more quickly this way.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Monday, November 11, 2013 11:29 AM
To: Sigbjørn Vik; Jeremy Rowley; public at cabforum.org
Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate handling

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.

-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
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>