[cabfpub] Upcoming changes to Google Chrome's certificatehandling

Phillip Hallam-Baker philliph at comodo.com
Tue Nov 12 09:44:50 MST 2013


I can provide several ways to do Gossip that are completely solid with respect to my security metric of a social work factor over 
time. I introduce the concept here:

http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00

What I cannot do is to provide a mechanism to allow a stand alone client to evaluate the Gossip traffic and use the output of the 
evaluation to gate certificate acceptance.


This is actually the reason that I remain a strong supporter of CT for the purpose of detecting rogue or compromised CAs but I am 
very skeptical of the value of performing the checks in the browser. I agree that doing checking in the browser would be desirable 
if it is feasible. But I cannot see a way to do that without at least one of the following:

1) Excessive data traffic and complexity.
2) Relying on the notary time servers as trusted.
3) Opening up the time window for vulnerability between cert issue and achieving transparency


At the moment, CT appears to be adopting option 2. The trust in the timestamp notary is considerably more limited than the trust in 
a CA. The Time notary cannot introduce a subject and cause the client to trust it. But the timestamp notary and the CA can collude 
from any point after the latest trusted timestamp the client receives.

I have developed schemes that close this hole but they either require the client to evaluate multiple notary time servers on an 
ongoing basis or they require the client to participate in the gossip. Neither approach is satisfactory.

One approach that may be viable is to have each browser provider pick one notary timestamp source as master and sign notary updates 
of that source. But that requires either a lot of signing or opening up the time window. And the chosen time notary is trusted for 
purposes of transparency.


Another approach is to rethink the application of CT as being a point defense against a particular attack which is a covert man in 
the middle attack by covertly suborning the CA and consider the control acceptable if it only permits the CA to be suborned overtly.

We can dramatically improve our development scope if we divide the problem into two trust levels:

1) Fire Alarm system

The client does not do any CT processing whatsoever but instead forwards certificates to an 'adjudicator' service that performs the 
CT processing, evaluation of notary logs, etc. Forwarding may be of every cert, every recently issued cert plus a sampling of old or 
a sampling of all certs.

2) Fire Alarm and Fire Door system

Performs full CT processing locally including evaluation of multiple timestamp notary logs etc. Notifies the adjudicator if a 
discrepancy arises and also blocks access to the site.


The frequency of CA compromises is very low compared to other vulnerabilities. Software holes occur far more frequently and will 
continue to occur. It is far more likely that a certificate will be issued to a legitimately credentialed bad actor than an attacker 
attempting to impersonate another party.

The value of CT is that it deters the attack. If the deterrence is effective, there should be no consequences to mitigate.

Fire Doors may be a useful security feature but the value of that feature has to be compared against the value of every other 
browser feature. I remain very skeptical of a claim that a vendor that refuses to support revocation, a control that is necessary to 
prevent a far more likely source of compromise is going to commit to a control that requires more resources to address a less common 
attack. 



More information about the Public mailing list