[cabfpub] Upcoming changes to Google Chrome's certificatehandling

[Ben Laurie]

On 12 November 2013 16:44, Phillip Hallam-Baker <philliph at comodo.com> wrote:
> 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.

That is not the purpose of gossip in CT. Its purpose is to reveal any
attempts to fork a log.

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

This is correct. But they cannot collude without later detection. So,
the cost of such collusion is that one or both get shut down.

As I mentioned in an earlier email, it is also possible to make the
system tighter, by making the time between issuance of a cert and
acceptance by browsers longer (there are various options here, but all
would have this effect).

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