Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

[Tom Ritter <[e-mail]>]

Thanks for this Bryan.  I'm going to echo Ben a bit:

On 6 August 2015 at 02:17, Bryan Ford <[e-mail]> wrote:
> It creates new privacy problems by requiring the client (browser user) to
> “opt out” of web browsing privacy in order to gain any security benefit.
> Either the user hands over all his browsing history to a remote “trusted
> auditor”, thereby opting out of privacy; or else the user remains fully
> vulnerable to the same kind of (potentially extended) MITM attacks that
> motivated CT in the first place.


If the Trusted Auditor mode is a default that requires Opting Out
instead of Opting In I think I speak for every author when I say we
will have considered this a huge failure and will rally against it as
much as we can.


> Could you explain how “the system as a whole” detects such misbehavior in
> the case of the state/ISP-level MITM attacker scenario?
>
> As I see it, if the client/browser doesn’t opt-out of privacy by gossiping
> his browsing history with a trusted auditor, then the client’s *only*
> connection to the rest of the world, i.e., “the system as a whole”, is
> through the “web server”, which may well be the same kind of MITM attackers
> that have been known to subvert the CA system.  The client never gets to
> communicate to the rest of the system - i.e., the legitimate CT log servers,
> auditors, or monitors - and so the client never gets the opportunity to
> “compare notes” with the rest of the system.  And the rest of the system
> (the legitimate log servers, auditors, and monitors) never have the
> opportunity to learn from the client that the client saw a MITM-attacked,
> forged set of CA certs, STHs, and SCTs.


In SCT Feedback the only connection to disclose data about Website A
is indeed website A.
In STH Feedback, assuming the client can resolve a Cert to a STH via
an inclusion proof (which we currently suggest via DNS, but other
mechanisms can exist, such as Tor) - that STH will be pollinated to
_any_ website.  And the split-view log will be caught. So that's how
the 'system as a whole' detects the issue.

The difference is of course because the SCT is private data that
reveals browsing history, the STH is not (not counting old-STH attacks
which we mitigate).


If an attacker can both persistently MITM someone to a website (or the
whole internet) and DoS the STH lookup mechanism (and compromise a log
and a CA) - yes, the attacker wins.

Attackers who can persistently MITM users forever are extremely
powerful and we have no way to defend against them except to make all
your client software just stop working.  This applies to the CA system
absent CT, it requires to the CA system with CT, and it applies to
software updates.  If you can write exploits, but not find bugs - just
wait for a patch to come out, block the update, take your leisurely
time reverse engineering, writing the exploit, and using it.

I don't mean to dismiss this concern, but a) I don't believe SCT
Feedback and STH Pollination cause privacy problems b) This problem is
so hard that no one is attempting to defend against it c) History
suggests such attackers are not all-powerful.  Or at least, we've
caught a lot of folks who could have gotten away with it that
supposedly had that capability and could have known better.




> Or are you saying (contrary to my prior understanding) that Chrome requires
> *all* CT certs to have multiple SCTs signed by different log servers?

As Ben said, the end goal is to use it for everything.  I don't know
when we'll get there, but in the interim there will probably be a
period of opt-in:
https://ritter.vg/blog-require_certificate_transparency.html


> But isn’t that precisely what happened in the prior COMODO and DigiNotar
> cases, where the MITM attacks were detected only when a few more
> security-conscious users compared the certificates they were seeing against
> what the rest of the world was seeing through nonstandard “side-channels”?


http://wiki.cacert.org/Risk/History and my recollection indicates
DigiNotar - Chrome Pinning google.com
TurkTrust - Chrome Pinning google.com
ANSSI - Chrome Pinning google.com
India CCA - Chrome Pinning google.com
CNNIC - that website indicates it was CT that caught it, but I think
that's a misunderstanding it was again Chrome Pinning google.com

The Comodo incident you reference, was that the mozilla.com cert in
2008?  That was someone just trying a RA portal and getting a cert:
http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/

Despite all the effort to find such certs manually, via MEKAI,
Perspectives, Convergence, Cert Patrol, and others - I'm not aware of
anyone ever catching a CA-signed misissued cert manually.


> With the multi-SCT approach, the amount of bandwidth consumed during TLS
> negotiation with every CT-supporting website increases linearly with n.
> With the scalable multisignature approach, n can increase to arbitrarily
> large size - a hundred, a thousand if needed - e.g., including all the
> public auditors, monitors, etc. - without any increase in the size of
> certificates, number of SCTs attached, or ultimately the bandwidth/latency
> overhead during TLS negotiation.

While we aim to keep SCTs small as Ben indicated - yes, sending 10
would be quite a bit.  I'm not sure of a great answer here.. I think
the onus is kind of on the community to curate and run a fewer number
of high-quality, mutually distrusting, different-juristictional logs.


> 2. Our original design for CT did indeed have certs served along with an STH
> and an inclusion proof. Unfortunately, CAs categorically rejected this
> approach because of the latency it introduced in the certificate issuance
> process. Personally, I think it would be a better approach. Now CAs are more
> accepting of CT, perhaps it would be worth revisiting the question with
> them?
>
>
> Agreed, that would be great.

I am most excited about the prospect of sending an inclusion proof to
a recent STH to the client - but I don't actually think the cert is
the answer. I think it's a TLS extension or (better) an OCSP staple.
Doing this would eliminate what I think is the weakest part of the
gossip document - the requirement to obtain a STH from a SCT (well a
cert) via some 'privacy preserving manner'.  (Which we, again,
theorize to be DNS, but I don't think that's the answer for everyone.)

If the STH was included in the Cert, that doesn't really change the game for me.
1) The STH could be a STH on the split view of the log, so the
immediate-decision security is no better that just sending a SCT.
2) The STH is too old. I don't want clients pollinate old STHs,
because as time goes on, old STHs will be rarer and will be indicative
of what website you visited. After 2.5 years there will only be 100?
1000? popular websites with that STH in the cert. So the old STH needs
to be resolved to a recent STH, and you pollinate _that_.

-tom